I have a linux (Ubuntu) server running and it is sending out messages to a group of clients over the internet.

Anyone with a desktop with a PCI card gets every packet. Anyone using an onboard ethernet - ie a laptop gets what I can only describe as "broken packets" generally about 10 seconds after start. I'm pumping out about 3200 bytes per second. The receiving buffers on onboard machines might get 31 bytes of a 40 byte message. The rest of the bytes are either dropped or are in the next message. The general effect of this is that within four seconds, the connection is broken between the server and the client - with subsequent fatal consequences to the client.

A few years ago I researched this and a tester who was using an onboard ethernet (desktop computer) had Comcast and after several weeks a Comcast techhie said something about the onboard ethernet had known problems with high bandwidth situations and was prone to dropping packets (which in the case of movies produces stuttering). But since my packets have essential data in them - it is fatal to the program/client. After my tester installed a PCI ethernet card the problem completely disappeared.

Is there anyway, using software, to work around this problem? Does anyone know what the actual cause is?

Thanks!

When you say "broken packets," what comes to my mind is jabber - which is a sign of a faulty network interface. Are all of the onboard laptop NIC's the same brand and model? If so, either the drivers could be bad for them, or they have hardware glitches out of the factory.

Is this transmission tcp or udp? Udp is designed to be connectionless. A client that has to use a lot of cpu may have some issues if the load gets too high. Many nic's have to use the hosts cpu to do normal tasks and work the nic. See if you can use ethertool or other tools to offload checksums to the nic for starters. Use top to see cpu loads.

As a general rule. Any normal tcp connection if OK up to 70% of bandwidth. That assumes a lot of stuff. I'd think that comcast tech is a goof. There is no difference in the actual quality of the two. An internal embedded nic connects to the pci bus in normal situations. In some laptops it might go though a pci to pci bridge then to motherboard. All should be able to handle any and all internet traffic. A standard nic is way faster than almost all isp's.

Yes, this is TCP. And yeah, the client is in a heavy load reading large files, etc.

Lately this is the situation... client connects and gets delayed while loading data so it doesn't check the buffer for a couple of seconds (Yay Microsoft!). Then when it does begin to get the buffers they are nearly full and while it is catching up on processing of the data the buffer splits/drops part of a message. Don't know why as there is plenty of room in the buffer by the time the split is encountered.

Well, I got a work around, by sending an "I'm busy" message to the server which effectively stops 95% of the traffic to the client until it's ready. Still makes me wonder about streaming traffic (ie movies). Maybe the server in that case is slower than the client?