Re: [Condor-users] Windows 2000 Server + Condor

["Matt Hope" <matthew.hope@xxxxxxxxx>]

On 4/24/07, Andrey Kaliazin <A.Kaliazin@xxxxxxxxxxx> wrote:
> Hi Matt
>
> It was not my intention to sound all-knowing and overconfident.

Not at all - just that your experience (and testing) might not apply.

> What I meant was that in the particular case of running windows server
> on a P4HT hardware the overall system performance (responsiveness)
> is likely to be higher with hyperthreading turned on.
> Condor apps may not see the boost, but the OS itself and other,
> non-condor services may.

This is an interesting case of conflicting goals when cycle stealing.
Many tweaks to scheduling for desktops are designed to improve
responsiveness as perceived by the user but may come at a cost to
throughput, scheduling parameters such as thread quanta are a good
example.

It may be worth knowing in advance in future (perhaps even now for
some) just what resources a VM is offering. For example we are
considering future blade purchases and trying to decide on dual verses
quad cores in multi socket systems. Certain applications may benefit
from running multiple threads either on the same core or different
ones (shared data requirements with some interdependency but
considerable parallel sections). If we were to begin parcelling the,
possibly 8, cores among multiple VMs we may want to arrange some with
2 cores on the same socket (sharing level3 cache) or entirely separate
to reduce the memory controllers work albeit with 1 more Hyper
Transport Link.

This low level reporting and management (for instance at the moment
well behaved jobs know how to set their cpu affinity - having condor
manage that itself would be nice) being integrated and discoverable
through condor will become more important to people with dedicated
farms.

> Also we had a case when on the Xeon-based workstations running Linux
> with SMP-aware kernel condor jobs were failing erroneously, when HT
> was disabled. With HT on, everything works flawlessly with one
> condor VM per node.

Indeed - a rather faster moving target than windows in that regard :)

Matt