On Monday, July 14, 2003, at 05:55 PM, Daniel Frimerman wrote:
The cable modem is plugged into a 10mbit ethernet card. Putting throttling will do, but isn't it strange that I'm capped at a certain speed, yet I can send out 10mbit?
This isn't strange at all, since your ethernet card/protocol stack has no concept that your cable modem is capped at a certain rate. There's no "signal" from the cable modem to tell your system that it is rate limited, or that you're sending more data than it can pass on (I have yet to see a cable modem that supports any kind of Ethernet flow control, and you're using 10mbps Ethernet, anyway).
Instead, packets are flooded out the interface as fast as they can. Presumably, your application writes data to the socket, which passes the data to IP, which passes it down to hardware (and yes, I'm simplifying this a bit)... If your app is writing data at or faster than 10mbps and doesn't stop, and the transport accepts the data and passes it down and doesn't stop (i.e. TCP isn't waiting for an acknowledgement), the NIC should receive this data at a high rate and send it as fast as it can, without stopping. This data eventually begins "pooling" at the point where the rate conversion occurs (from 10mbps to, say, 256Kbps), and most likely begins overflowing buffers in whatever is doing the rate conversion, which results in the packet loss.
Anyone else has the same problem as I do?
Yes, anyone doing the same thing you are.
Use a protocol that does flow control, such as TCP, or put your own throttling into the sending loop.
Doesn't this mean that if I create a UDP socket and send it as fast as possible it would reach ~10mbit, since UDP has no flow control?
Absolutely. Very possible, and seems like that's what's happening to you.
I thought cable modem caps were physically on the cable modem itself which I
thought would block the packets until speed is synchronized :(
Even if the data rate is capped on the cable modem, your system still has to somehow KNOW that it should slow down, or that it should stop sending data to avoid overflowing buffers. There's no magic there.
In your example it sounds like there is no "end-to-end" flow control present - no layer 2 flow control, no layer 4 flow control (i.e. TCP), and no application layer flow control (your app has no signaling of any kind, it simply generates bursts of data). You send data to some device on the network faster than it can send out. Data gets buffered, and those buffers (eventually) overflow. In short, you need some sort of flow control along the network path to prevent data from getting dropped.
Incidentally, it's very possible that the cable modem itself isn't limiting your sending rate, but the rate limiting is happening farther back toward your cable provider. But it doesn't really matter much for your problem.
If I send too fast, above my cap limit, does it mean I packets? If yes, I
can't rely on their arrival can I?
If you send faster than some device along the path can handle, and you have no mechanism to slow or stop you, then yes, you will eventually lose packets.
Think about it this way - let's say that you sent data at 100mbps to your cable modem, and it was able to forward on to the cable provider at 100mbps as well. The cable provider can even send your data to the Internet at 100mbps, and so on, until it finally gets to where you're going - another PC with a *10*mbps Ethernet card. If the 2nd PC is plugged into a switch, the switch might be able to buffer a little bit of the 100mbps data that it's trying to squeeze down the 10mbps pipe, but if you keep sending data at 100mbps, the switch eventually won't be able to hold anymore. Now, in this case, how does YOUR system know that it needs to slow down? It's the same basic situation, we've just moved the "point of congestion" farther down the network path.
And you, as an app writer, can NEVER "rely" on packets arriving without some sort of mechanism for data acknowledgment, whether that be a reliable transport (like TCP), some kind of mechanism built into your application, etc.
Ian
================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/
To unsubscribe use mailto: [EMAIL PROTECTED]
==================================================================
