Working as Expected (Jul 13 2009) |
![]() |
| log in |
Message boards : Technical News : Working as Expected (Jul 13 2009)
Previous · 1 . . . 6 · 7 · 8 · 9 · 10 · 11 · Next
| Author | Message |
|---|---|
As of approximately 1:30am UTC, it looks like there is a nice fat spike in uploaded (probably actually reported) results. Then you obviously don't know me very well, nor my sense of humor. Its ok, a lot of people don't get my sense of humor until they really get a chance to know me. ____________ | |
| ID: 920092 · | |
Just noticed that even though there was a download dip and upload spike in the graph that ML1 displayed, that when looking at the packets there is virtually no variation on the uploads. Yes, good point. This tells me that downloads are limiting upload speeds. This was discussed earlier. As you know, we should expect upload and download speeds to be highly correlated. | |
| ID: 920093 · | |
Hey! Shame on you... Cynicism doesn't become you. Shame on you for missing my pun-ish humour and the pun on a few lines from an old Star Trek episode... Is it that an Ameri(k)an UK divide/divergence? ;-) Cheers, Martin ____________ Mandriva Linux A user friendly OS! See new freedom Mageia2 The Future is what We make IT (GPLv3) | |
| ID: 920095 · | |
Just noticed that even though there was a download dip and upload spike in the graph that ML1 displayed, that when looking at the packets there is virtually no variation on the uploads. OUCH! That's a direct link to Cricket. Very antisocial... I'll capture the latest graphs and link them to my hosting. Interesting point there! Note that there are many bits in a packet and so the packet numbers will be a ratio of the bit rate, assuming that the average packet size remains the same. More musing... Regards, Martin Bit rate: And the packet rate (x2 vertical scale): And the bit rate and packet rate (x2 vertical scale) combined: Note: Green = downlink, blue line = uplink. (Note 2: Fixed plots. DO NOT LINK DIRECTLY TO CRICKET!) ____________ Mandriva Linux A user friendly OS! See new freedom Mageia2 The Future is what We make IT (GPLv3) | |
| ID: 920098 · | |
Just noticed that even though there was a download dip and upload spike in the graph that ML1 displayed, that when looking at the packets there is virtually no variation on the uploads. If a live link is OK for Eric Korpela, I think we can survive one in Technical News - remember we're only using Campus bandwidth for the forums (and Cricket bandwidth for the actual semi-static* image), not getting in the way of the Hurricane Electric data. Surely Andy's point is that some packets (setting up/acknowledging the connection) will have many fewer bits than the data packets? So when the downloads allow a space, many more of the upload packets contain real data, and there's much less administrative chitter-chatter. * The cricket graphs only update once every four minutes, so the data-rate is much less than, say, streaming. | |
| ID: 920103 · | |
|
Aside: If a live link is OK for Eric Korpela, I think we can survive one in Technical News - remember we're only using Campus bandwidth for the forums (and Cricket bandwidth for the actual semi-static* image), not getting in the way of the Hurricane Electric data. ... That assumes that Cricket doesn't get touched if the page is cached. There's previous mention not to directly link to avoid loading the Cricket box. (Not a problem of bandwidth but more that Cricket is not administered by s@h and is supposedly for the benefit of on-campus users only. Abuse it, it will get switched off. [Mods comment here?]) In any case, a direct link is futility. Tomorrow, whatever you're trying to show will have scrolled off the side into oblivion. Hence, just simply use a link to a static copy hosted somewhere else. Easy enough even for a complete non-webbie such as myself! Cheers, Martin ____________ Mandriva Linux A user friendly OS! See new freedom Mageia2 The Future is what We make IT (GPLv3) | |
| ID: 920108 · | |
|
| |
| ID: 920111 · | |
Aside: If you look further down this very thread (message 918592 - and notice how I took out the nowrap to avoid the excess loading of posts below the "all except the last 75" cutoff), you'll see a static Cricket image hosted off my Imageshack space, again precisely so that we could freeze a moment in time and study it. Been there, done that. I also had a live Cricket image moderated a couple of weeks ago (I had quoted someone else - I think that two copies of the same image in a thread is no worse for bandwidth than a single copy). The Moderator message said "The Link to the Cricket Graph cause headaches for what happens over the Berkeley wire, everytime a user look at the forum thread it cause a query to the Graph. Which also goes up the hill eating network bandwidth. It is also hosted on a Server that Seti does not own." Whilst I would not mind honouring a request from the Cricket Admins not to link their resource (though it would be a shame to lose it), the other reasons given don't seem to hold water. So I'm not sure how "official" the embargo on live links is. | |
| ID: 920113 · | |
Just noticed that even though there was a download dip and upload spike in the graph that ML1 displayed, that when looking at the packets there is virtually no variation on the uploads. ... (Pale green is bits, dark green is packets. Thin blue is bits, thick blue is packets.) Looking closely at the period Mon 19:00 - Mon 21:00: 19:00: Downlink: Both the bit rate and the packet rate sharply ramp downwards; Uplink: Bit rate jumps stepwise to a maximum, the packet rate sharply ramps downwards; 19:30: Downlink: Both the bit rate and the packet rate sharply ramp upwards to a maximum; Uplink: Bit rate jumps stepwise down to a background average level, the packet rate sharply ramps upwards; 19:45: Downlink: Both the bit rate and the packet rate slowly ramp down; Uplink: Bit rate slowly ramps down, the packet rate remains steady; 20:20: Downlink: Bit rate remains at a maximum, the packet rate slowly ramps up; Uplink: Bit rate slowly ramps up, the packet rate remains steady; 20:50: Downlink: Bit rate remains at a maximum, the packet rate transitions to a noisy average; Uplink: Bit rate and packet rate transition to a noisy average. OK folks: The diagnosis is? Regards, Martin ____________ Mandriva Linux A user friendly OS! See new freedom Mageia2 The Future is what We make IT (GPLv3) | |
| ID: 920114 · | |
Aside: I'm not 'official' on these forums. I'm not Cricket or s@h admin. And you've obviously 'been there. done that'. Myself, I just consider it to be good sense and good netiquette. Also a "very good idea to avoid spoiling the party". I'm happy to hand the issue over to the mods for comment. Meanwhile, the case in hand is the interesting interaction of downloads poisoning uploads... Your comment on that? Regards, Martin ____________ Mandriva Linux A user friendly OS! See new freedom Mageia2 The Future is what We make IT (GPLv3) | |
| ID: 920119 · | |
|
Have to say I wasn't aware of the request not to link directly, have been fairly busy lately, and not here as much as usual. | |
| ID: 920122 · | |
I'm happy to hand the issue over to the mods for comment. My quote - you've obviously noticed we're skating on thin ice here! - was designed to raise the possibility that the mod in question - who I won't name - might have been operating 'freelance', with the best of intentions but ending up blocking a useful tool (sometimes a live version is relevant, unlike this discussion) on the basis of a false premise. I'd prefer it if admin comments, rather than a mod, on technical matters: obviously the mod might have been passing on an official 'admin' request, but that wasn't how it was phrased, even in the bits of the message I've left out. Meanwhile, the case in hand is the interesting interaction of downloads poisoning uploads... Your comment on that? I've already posted my theory that when the link is less than saturated, a higher proportion of data packets, as opposed to administration packets, get through. | |
| ID: 920125 · | |
Just noticed that even though there was a download dip and upload spike in the graph that ML1 displayed, that when looking at the packets there is virtually no variation on the uploads. I think I detected a signal from ET in that waveform! :D ____________ SETI@home classic workunits: 93,865 CPU time: 863,447 hours Join the BP6/VP6 User Group today! | |
| ID: 920129 · | |
Hey! Shame on you... Cynicism doesn't become you. Ah, yes. I the humor did go right over my head! I'm not familar with that particular lined, which is why I think I missed it. :) ____________ | |
| ID: 920131 · | |
I'm happy to hand the issue over to the mods for comment. ONLY in that we are not the authority on the issue. But then also there is good common sense. You play your ghetto blaster at 95dB and you can expect to get your wires cut. If I as a busy Cricket admin noticed a higher than normal hit rate from outside that gave cause for note, or just slowed things for when internal people wished to check, then simplest and quickest is to just block the external load and remove an impending headache. We then lose a valuable reference for those that know about it. It's very easy to avoid such a risk, especially so for something for which s@h may be seen as a headache for the rest of campus... (You can't easily hide a heard of a few thousand desperate crunchers!) Meanwhile, the case in hand is the interesting interaction of downloads poisoning uploads... Your comment on that? Nearly... My thoughts are that the 'administration' packets are the more important and critical and avoiding those getting dropped avoids needless resends of the associated big data packets. You also get the required resend requests for when a data packet gets dropped. More interesting is the outlined phases that the link goes through over the 2 hour period. Note also the difference from the presumed server-side outage earlier in the chart. Regards, Martin ____________ Mandriva Linux A user friendly OS! See new freedom Mageia2 The Future is what We make IT (GPLv3) | |
| ID: 920134 · | |
I'm happy to hand the issue over to the mods for comment. I believe this was a current hot-button topic recently, and I believe Eric himself chimed in and said that it wasn't an issue linking to the cricket graph. ____________ | |
| ID: 920137 · | |
Meanwhile, the case in hand is the interesting interaction of downloads poisoning uploads... Your comment on that? Nearly... My thoughts are that the 'administration' packets are the more important and critical and avoiding those getting dropped avoids needless resends of the associated big data packets. You also get the required resend requests for when a data packet gets dropped.[/quote] Nearly.... It's also a case of timeouts. Packets come in, and if the ACK can't find its way back to the sender in a reasonable amount of time, the sender will time out and send again. It's possible that the packet being retried is still in a buffer somewhere. We also seem to forget that each TCP connection, sending no data at all, has a cost. It takes up space in the *NIX kernel for the "handle" and the IP stack has to service it periodically. We should not forget that, because Eric's "I just increased the bandwidth" works by taking open, stable connection handles, and closes them if they aren't likely to get turned over to the right process(es) on time. I'm not an expert on Red Hat or Apache, but the same problem exists in other environments. The simple answer is: you want just enough activity to keep everything at the most efficient speed -- if that's 80mbits (which feels about right) and the average connection can do 250k, then 320 connections is perfect. You can probably do double that before you're in trouble, but that's the idea. ____________ | |
| ID: 920159 · | |
|
| |
| ID: 920161 · | |
|
Observation FWIW. Joe | |
| ID: 920217 · | |
I'm happy to hand the issue over to the mods for comment. I didn't actually read him saying anything, but he did it himself in Panic Mode (20) five days ago, and the Panic Mode threads are pretty heavy traffic - I took that as a strong hint! (Sometimes a picture is worth a thousand words). But I agree we should exercise restraint in linking live, and just post a reference link if we're just explaining to a new volunteer that things are busy, and a static external image like Martin and I have used if we want to dicuss events at a particular moment in time. But then - note that if someone follows a link to the full Cricket page, they put more strain on the Cricket server with a request for (usually) two graphs and a page of data, instead of just the image file! Sorry for delayed post - I had it in preview when maintenance struck! | |
| ID: 920259 · | |
Message boards : Technical News : Working as Expected (Jul 13 2009)
| Copyright © 2013 University of California |