Basic questions about telecommunications

There are several aspects to the communication process which can cause this sort of "burstiness".

One is the phone line itself (the modem-to-modem transmission). Modem connections these days usually use V.42 error correction technology. The data being sent is broken up into frames or packets (which may have separation points that have nothing to do with the underlying TCP/IP packets). The receiving modem will validate a checksum or CRC on each frame, and if it's bad (e.g. as the result of some line noise, corrupting a bit in in the frame) the modem will request that its peer retransmit the entire frame. The data won't be delivered from the modem to your PC until it has been successfully received (with the correct CRC) and you'll observe a brief "stutter" in reception during each such error-correction... often followed by a burst of rapidly-delivered data, as those frames which were in transit behind the damaged one are delivered almost instantly.

TCP is also a burst-prone technology. The sending system will gradually increase the rate at which it transmits packets (and the number of packets it transmits without waiting for an acknowledgement) until something goes "sproing" (that is, a packet is lost due to errors, or discarded because some router in the path decides that its buffers are full). The loss of a packet causes the receiving system to send back a "Hunh? Please resent", or to not send back an acknowledgement... and these will require retransmission of the lost packet. Net result is that the net transmission speed varies, as a result of packet loss and network congestion levels.

--
Dave Platt                                    AE6EO
Friends of Jade Warrior home page:  http://www.radagast.org/jade-warrior
  I do _not_ wish to receive unsolicited commercial email, and I will
     boycott any company which has the gall to send me such ads!

There's a million reasons why speed varies.

It could be line noise, where the modem continually re-negotiates for the best speed it can.

It could be an iffy line connection, where it works "perfectly" at lower speeds, so the modem re-negotiates for a higher speed where it (consistently) fails and falls back again.

It's a bit hard to diagnose this type of problem, more so if you have modem that does not have good diagnostic feedback on the last call.

If it *IS* noise or line limitations, it might help to force your modem to 14.4, and see how your connection speed goes. You're looking at consistency rather than raw speed in this case.

If it IS stable, your line might be going through a pair gain, used by Telstra to double up on a single copper pair, and splitting up when it gets near your place. It saves copper wire when they have many subscribers, plenty of nodes at the exchange, but little copper.

If this is the case, you'll see phone calls work well (albeit sometimes with crosstalk), Fax works well (9600/14.4) and plays merry hell with modems that go faster than that.

Good luck with convincing them to fix it though. Even if they DO have copper to spare, it ends up being a significant resource waster for one guy who's whining about his modem. Doesn't hurt to whine though, you might get lucky.

Another option is that it has nothing to do with you or your carrier, but with your ISP. I've seen bodgy speed throttling techniques that don't work as well as they should. Though that said, they shouldn't be going through that anyway, as the modems have inherent speed limitations to keep them happy anyway.

--
I have a speech impediment... my foot.

On 12/31/2010 5:30 PM John Tserkezis spake thus:

Thanks for your reply. However, I'm not really reporting or trying to fix a problem here. I think my connection, for the most part, works fine. (Actually, there is an easy fix for my problem: $$$.)

I'm just trying to understand *why* it works that way (speed constantly bouncing between two "notches"). It seems like it's *supposed* to work that way; why?

I was also going to say something about how it might have something to do with the negotiation process between client and host, the "REQ/ACK" process or the equivalent. Not knowing the details of TCP and all that, I can only guess at what this mechanism is.

Details. I want the gory details.

--
Comment on quaint Usenet customs, from Usenet:

   To me, the *plonk...* reminds me of the old man at the public hearing
   who stands to make his point, then removes his hearing aid as a sign
   that he is not going to hear any rebuttals.

I didn't entertain the packetising of data, because that is faster than the graph logging anyway, so you shouldn't even see it.

Besides, from what I remember of modem links, it never behaved that way anyway, by the time the speed graph showed anything of interest, it was reasonably steady.

What's the timing of your graph anyway? How frequently does it take a sample?

--
I'm not opinionated, I'm just always right!

*What* is being reported -- the number of bytes (bits) per second leaving some "upper level" of network software? Or, the actual speed that the *modem* is operating at? (I suspect the former unless your tool knows how to query *your* modem, directly, for this information).

So, you have some process in the PC that starts and stops sending bytes to the modem. The modem probably has a buffer (even if it is a software modem *in* your PC) that it fills up with bytes "from" your PC... then, empties into the phone line... lather, rinse, repeat.

The modem typically doesn't signal the PC after *each* byte has been pushed out onto the phone line -- that would involve too much overhead on both sides. Instead, it imposes a certain amount of hysteresis on the "signaling". So, a 100 byte buffer says "Full" when it receives it's 100th byte from the PC.... but, doesn't say "not full" until it has pushed maybe 80 of those bytes out onto the phone line.

I.e., on a very short time scale, it looks (from the PC's point of view) like the modem is operating VERY FAST (gee, it gobbled up those 100 bytes in less than a millisecond) then very slow (gee, it hasn't asked for ANY more data for dozens of milliseconds).

(No, this isn't your "problem". Rather, just an example of how things aren't "continuous time systems" when it comes to this sort of thing).

Modern modems autonegotiate connection speeds -- based on the capabilities of the two modems talking to each other *and* the line conditions in effect from moment to moment.

The connection speed is sort of like the "carrier frequency" (I am grossly misstating things here just to give you an analogy) of your local radio station. Your receiver has to be "tuned" to the same frequency as the transmitter for reception to occur. The two modems do this continuously while communicating.

ON TOP OF that "carrier", you have your actual data rate. To further push the radio broadcast analogy, that's like the rate at which the announcer is talking -- someone who talks slow vs. someone who talks fast.

[again, this is REALLY a bogus analogy]

The system at the other end of the line (and there can be several of them cascaded, in effect) can throttle the data flow. E.g., there is something like the output buffer of *your* modem on the other end acting as an "input buffer". It fills and empties in non-continuous ways based on what *it* is talking to.

Etc.

You can also have underlying "infrastructure" that further distorts these numbers. E.g., the presence of a SLIC96 can limit available bandwidth (though usually to something a lot less than what you appear to be seeing) simply because

*it* has a limited bandwidth capability that it imposes on the lines that it services.

Speeds upwards of 33.6Kbps tend to be more sensitive to line noise, distance from CO, etc.

You could also have a really noisey line and the noise might come and go "periodically" -- forcing the modem(s) to change speeds and/or request retransmissions "regularly".

It's really hard to say what you are experiencing without actually looking at your line. As a starting point, you can see if you can query your modem for statistics about the last call, etc. (doing so varies by model, etc.)

Hint: make a note of the IP addresses of various "stable" sites. When your name resolver isn't working, you can use these numeric IP addresses to verify that the problem is, in fact, with the name service and not "The Network".

IIRC, there are some public sites that will provide a *manual* name service that you could use in a pinch (assuming you keep a record of their NUMERIC IP addresses)

On 12/31/2010 6:53 PM John Tserkezis spake thus:

As I said, period seems to be about a second. The only time I see a straight line is if I upload something. I think FTP transfers are a lot more steady as well. Otherwise, the transfer speed (incoming) is constantly changing.

I could post a snapshot if you like.

Doesn't seem to be anything wrong with the modem, the phone line or the system. It just likes to behave that way.

--
Comment on quaint Usenet customs, from Usenet:

   To me, the *plonk...* reminds me of the old man at the public hearing
   who stands to make his point, then removes his hearing aid as a sign
   that he is not going to hear any rebuttals.

Sure, I'd like to see the timing.

--
Never draw fire, it irritates everyone around you

On 12/31/2010 7:24 PM John Tserkezis spake thus:

Here:

Time divisions are ~3 seconds. This transfer (downloading a picture) bounced between 3.0 and 4.4 K (which I ass-ume means kilobytes?).

On longer transfers the pattern (sawtooth "wave") becomes very regular.

--
Comment on quaint Usenet customs, from Usenet:

   To me, the *plonk...* reminds me of the old man at the public hearing
   who stands to make his point, then removes his hearing aid as a sign
   that he is not going to hear any rebuttals.

OK, you're talking about 9 seconds or so between each drop and rise, that's not a protocol issue, it's way too long. It might be a re-negotiation timing, or something your ISP is doing.

--
What does Santa do at a house with no chimney?

On 12/31/2010 8:39 PM John Tserkezis spake thus:

No. Maybe I wasn't clear: the time between the time divisions (vertical lines) is about 3 seconds, so it's about a second between each drop and rise. The display updates about once a second. (3 samples/time div.)

--
Comment on quaint Usenet customs, from Usenet:

   To me, the *plonk...* reminds me of the old man at the public hearing
   who stands to make his point, then removes his hearing aid as a sign
   that he is not going to hear any rebuttals.

That makes even less sense. If you meant 0.3 Seconds per horizontal division, that would equate to one second (or thereabouts) per each rise or trough, allowing that I counted about three divisions for each. So it appears you've left out a decimal point.

For one second, that might be a bit quick for a re-negotiation, but I still don't buy the protocol packetising that's doing it.

Have you tried using another graphing logger? It *might* be that it takes a snapshot, rather than a real average over the timing period.

--
I am free of all prejudice. I hate everyone equally.

On 12/31/2010 9:41 PM John Tserkezis spake thus:

No. You're just not getting what I'm trying to describe.

It's really simple. The display updates once a second. Each vertical division--the space between two vertical green lines--is 3 seconds. So there are 3 1-second samples between each pair of vertical lines. The smallest feature in the display (i.e., the resolution) is 1 second. Does that make sense?

I don't *have* another graphing logger. This is the one that comes with the firewall.

Here's another snapshot:

Notice how regular the pattern is here (in this case, it's bouncing between 4.4 and 4.9 K/sec). The same flat tops of the waves (minus a few bobbles here and there). I've seen such a display that was absolutely perfectly uniform across the entire display on a long download. (This was downloading a PDF; line connection speed was 49.2, the highest possible speed with my setup).

--
Comment on quaint Usenet customs, from Usenet:

   To me, the *plonk...* reminds me of the old man at the public hearing
   who stands to make his point, then removes his hearing aid as a sign
   that he is not going to hear any rebuttals.

You're describing two different timings.

If it's three seconds per horizontal division, and as per the image, I saw (about) two to three divisions per peak or trough, (not counting the steady bit on the right, that equates to six to nine seconds per peak or trough. That's how it's counted.

You're talking about the little variations? I get wider variations that that myself. I just did a test here, and I'm getting quite significant variations over the download. But, I'm on cable, and I don't have an active landline modem connection to test otherwise.

In any case, now I officially don't know. Sorry for wasting our time. :-)

As far as speculation goes, one could guess that the internet IP packets might have something to do with that. Everything gets to your place in packets. If a few packets get there late, they're still ordered correctly, but just a little late.

There would be significant (depending on your needs) "jitter" in that on average, you may have quite constant speeds, but from second to second, not. You basically don't have any control over the intermediate data handlers from the site you visit to your destination. It's actually a bad thing when you're using it for live voice/video communication (Skype etc), because that type of communications *needs* a constant supply of data, but the buffering works well enough that you don't notice too much.

In effect, you're insulated from the effects of Real Life (TM).

--
Follow-ups to alt.nobody.really.cares

On 12/31/2010 10:54 PM John Tserkezis spake thus:

Phew. Finally; yes, that's what I'm talking about, the "little" fluctuations (between ~4K and ~5K in that second snapshot). They intrigue me because they're ubiquitous (they happen all the time) and they're sometimes so regular; it seems like a pattern that must have something to do with the underlying transfer mechanism. If it's indeed jitter, it's damned regular jitter.

Since at this point we both seem to be going on pure speculation, I'll just thank you for your participation so far.

--
Comment on quaint Usenet customs, from Usenet:

   To me, the *plonk...* reminds me of the old man at the public hearing
   who stands to make his point, then removes his hearing aid as a sign
   that he is not going to hear any rebuttals.

Methinks you're looking at the effects of roundoff error. There are not enough packets used for the download test, so the graph is rounding off the result to the nearest convenient significant figure. A running average, with larger time slices, would yield a much smoother and more realistic curve.

--
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

On 1/1/2011 12:11 AM Jeff Liebermann spake thus:

But as I watch the display during a download, I can see the rate *very regularly* alternating between two definite speeds (like 4.4 and 5.9 K). As you can see, the pattern is visible, at least according to this display. Doesn't that tell us something about how the transfer is taking place? Or is this just a regularly repeating roundoff error?

In fact, I can tell when the transfer rate is faster or slower, based on the display: it'll bounce between the same two speeds--that never changes--but the "flats" on the upper part of the line will be longer, meaning it's spending more time at the faster speed. The difference is actually noticeable, in the time it takes to render web pages and such.

--
Comment on quaint Usenet customs, from Usenet:

   To me, the *plonk...* reminds me of the old man at the public hearing
   who stands to make his point, then removes his hearing aid as a sign
   that he is not going to hear any rebuttals.

LOL

--
Live Fast, Die Young and Leave a Pretty Corpse

Toss a coin. From the pattern of heads and tails, I can see a very regular pattern of randomly alternating heads and tails. OK, bad analogy, but I thought it was cute. It might be doing 5.75Kbits/sec and alternately rounding off to the nearest convenient value. Most speed test software these daze is made for DSL or cable modem speeds. They use fairly short sampling times, because with the higher speeds, it's a fair assumption that there will be a sufficient number of bytes downloaded to get a reasonable value. However, the same software at dialup speeds is going to see far fewer bytes of traffic, and therefore generate a more granular result.

I think this would be a good time for you to disclose how you're running this test and what hardware, OS, and software you're using. I don't like guessing (even though I do it quite often).

It really depends on what your mystery application is doing and how large or long a sample it takes. If the sample is too short, you'll get roundoff error. Looking at your usenet news header, User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) it appears that you're using an older copy of Windoze, possibly Win98, and a 3.5 year old out of date copy of Thunderbird. Therefore, I won't suggest you use the XP performance monitor to get a better picture.

Incidentally, if you want to do useful performance measuring, with clues as to what's going on behind the magic curtain, I suggest you look at IPerf and JPerf.

You may have to update your version of Windoze and Java in order for it to run properly. You'll find a few IPerf servers available on the internet, but they're usually reserved for specific users in order to avoid overload.

--
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

On 1/1/2011 4:19 PM Jeff Liebermann spake thus:

OK: Win2K SP 4; computer is (reading from the Windoze "System Properties" dialog here as I can't remember the exact MB brand): "x86 Family 6 model 8" (Pentium IV???), running at, I believe, 700-something MHz, 786 MB RAM. Yeah, not enough RAM, not very fast clock speed by modren standards, but sheesh, should be able to keep up with a lousy 56K modem even running full blast, dontcha think?

Test application is Firefox, which is recent (not that it should matter, right?): v3.6.8. The latest line-speed display I uploaded was while downloading a PDF of a few megabytes.

Anything else you want to know? Can't tell you the model mfgr., except that it's a cheapie I got at the local computer guy's store. Nothing else fancy; no VPNs, PC-Anywhere, proxies, etc., etc.

Thanks, I'll look into those.

--
Comment on quaint Usenet customs, from Usenet:

   To me, the *plonk...* reminds me of the old man at the public hearing
   who stands to make his point, then removes his hearing aid as a sign
   that he is not going to hear any rebuttals.