NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Reference: network issues on conduit feed
There is the distinct possibility that if your queue isn't large enough,
the queue for that machine is 1.8gig which from my understanding 'should' be large enough
you could have a problem in processing all the data before it gets overwritten in your queue if you didn't take the increased data volume
the machine that was receiving conduit (I have since canceled the feed due to the latencies) reported CPU usage at the time of extreme latency as: ldm@unidata3:~/util/models/mrf201$ uptime 16:57:33 up 3 days, 23:22, 2 users, load average: 0.08, 0.14, 0.10
Your HRS latency shows the hit in latency starting today:
the interesting thing in noting latency is that the IDD topology map showed very high latencies for both myself and PA which run through abilene (at least mine does) ... http://weather.bgsu.edu/files/jweber/oct_10_2005_2054z_IDD.gif also note the feed from TAMU had lower latencies but were still 'up there' additionally if you compare the latencies from all three sources together: http://weather.bgsu.edu/files/jweber/conduit.gif that TAMU was fairly consistent yet slow... however IDD and ATM had huge spikes. this would seem to indicate that the downstream machine (unidata3) was not the problem... with that in mind I examined the 'abilene weather map' to see what it reported and as is shown below it was very busy. http://weather.bgsu.edu/files/jweber/abilene.png so... is it possible that the hops through abilene caused the majority of the problem, and that in fact that route is too overloaded to handle the additional large feeds? unidata3 was basically sitting there waiting for the data with a queue that should be large enough... the routes from boulder to both ohio and PA according to the topology map were slow... and extreme differences were demonstrated between the IDD ATM and TAMU feeds... I'm certainly not a network expert but there does seem to be some logic there.
gembud
archives: