Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
|
Hi, Thanks for the reply. > Just so I'm clear, this is one single HTCondor pool -- with HAD, only one negotiator is running at any one time? Yes it’s a single flock, across our organization’s network which spans several countries, sites and subnetworks. I’ve checked that despite HAD there is only 1 single negotiator daemon running. > that job RANK is just a preference, but if, for some reason, the job doesn't match any idle machines for the preferred RANK, HTCondor will find machines that are not RANK-optimal. Is there any ways to get some more diagnostic about how the matching is done? When doing condor_q -better-analyze on a job, REQUIREMENTS is listed but not RANK. On the CM side neither /var/log/condor/NegotiatorLog
nor /var/log/condor/MatchLog give any specific info about that either. At this point, we’re not seeking to submit first to computers based on same location, just on computing power. I am also trying to figure out if it’s possible to do it (as suggested by the manual) on the submitter’s
side without, if possible, changing the matching rule for the whole flock as we may later on expand our flock and merge with one another division / program within our organization is currently planning to establish. Their scientists and ours may not have the
exact same need in term of raw computing needs. I’ll have a look into setting up a schedd attribute as you suggested for country of origin though, it’ll help for better reporting and tracking who send jobs from where.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– As part of our emissions reduction strategy, please only print this email if necessary |
