next topic »

[Reply #255 on:]

Can you check you MSS value after the connection is established?

1460 (surprise!)

This is the value in the MSS register. I also checked that this is value in the TCP packets when the connection is established.

The packet sniffer also analyses the stream of packets and tells me how much data is 'flying' when I get the error (ie. how much data has been sent without an 'ACK'). It's 1920 bytes, ie. the W5100 is obeying the value of MSS when it sends the 1514 byte packet.

So...there's no obvious errors. Where does the 'fragmentation needed' message come from?

[Reply #256 on:]

Something must be up with your MSS. I have used several makes and models of routers, and none had a MTU over 1500. If the w5100 tried a 1515 byte packet through any of my routers, they would all return that message. The packet is too big for me. Break it up into smaller pieces.

On a connection to Yahoo, If the w5100 used an MSS over 1440, it would get the same message if I tried sending a packet with 1460 data bytes.

[Reply #257 on:]

I have wondered if writing to the SnMSSR register makes a difference.

I tried that a while ago but I'll give it another go.

Nope ... makes no difference. That register seems to be just for information (exactly as the docs seem to imply).

[Reply #258 on:]

Something must be up with your MSS. I have used several makes and models of routers, and none had a MTU over 1500. If the w5100 tried a 1515 byte packet through any of my routers, they would all return that message. The packet is too big for me. Break it up into smaller pieces.

I think we need to find hard documentation for this, the people who made the W5100 aren't idiots.

What exactly is "MTU" as applied to an IP datagram (and is it the same thing as "MSS")?

[Reply #259 on:]

Those people were really smart, but not perfect.

Maximum Transmission Unit = biggest total size of packet allowed. 1500 on all my routers
Maximum Segment Size = MTU (1500)  - header size (40) = 1460

So...
1460 (your MSS) + 54 (your header size) = 1514 (too big)

[Reply #260 on:]

So...
1460 (your MSS) + 54 (your header size) = 1514 (too big)

54 isn't my IP header size. 54 is IP+Ethernet.

I just sniffed a video playback on the local LAN (through the same router) and all the packets had 1514 bytes in them.

[Reply #261 on:]

Next step...

I modified my web server so that when it sends a file it just writes a big packet then freezes. I wanted to vary the packet size and find out what works.

On the local net it seems to work according to theory. I can send 1460 bytes no problem, if I try to send 1461 I get an error "Malformed packet". This seems to indicate my router works.

With my mobile phone it fails at 1453 bytes - seven bytes less than MSS. 1452 bytes is OK but 1543 bytes causes the "fragmentation needed" message. I can only guess there's a bug in a router downstream from mine. Sending packets with the "don't fragment" bit set is unusual so it wouldn't show up with normal PCs, etc.

If the problem's downstream then there's not much I can do about it. I've decided to make my network driver limit the data in the TX buffer to a maximum of 1024 bytes (ie. two disk sectors). I've done a quick test and it doesn't noticeably slow down the transmission speed and sending whole disk sectors at a time is good for having multiple connections open - the SD card will work optimally.

Now all I need is to finish the web server :-)

[Reply #262 on:]

Thanks, fungus. That is good to know.

BTW, I just found out the new gigabit routers will take ethernet packets in excess of 9000 bytes.  

But 10/100 routers are still limited to 1500 bytes (1492 for the original ethernet spec. Mine are ethernet V2). That is why earlier, I mentioned that sending packets with a size over 1000 bytes is not a good idea.

"Occam's razor". 

[Reply #263 on:]

But 10/100 routers are still limited to 1500 bytes (1492 for the original ethernet spec. Mine are ethernet V2).

1492? That's an interesting number. See above...my packets started failing at 1492 bytes.

[Reply #264 on:]

I have no idea how they picked 1492. I'm not sure how they picked 1500. You would think they would pick a nice, round binary number, like 512, 1024, or 2048. ??

Add: I did not think about this, but my routers can route your packets by the connection state. I can route a "new" connection state packet (the request for the connection) one way, and once the connection is "established", I can route you an entirely different way. Maybe that what your provider is using. And one of the "established" routers has a smaller packet size.

[Reply #265 on:]

I have no idea how they picked 1492.

They were Spanish? 

It's sort of cool that I came up with that number independently of the spec... :-)

[Reply #266 on:]

Maybe there is some historical significance to that number.

But there is another reason for this post. After some experimenting this morning, I found an interesting phenomenon. I designed a test the other day using a lot of data sent over a very restricted connection (56k). The page was large, and I let the w5100 decide what size packet to use, I would guess based on the MSS. The download took 17 seconds.

I wanted to see what difference there would be if I controlled the packet size like I usually do. Today, I decided to limit the packet size to a maximum of 600 bytes, and added a delay(1) in a loop until the TX buffer was empty, then sent another 600 bytes. The file download time went from 17 seconds yesterday to 4 seconds today. Less than a  quarter of the time using a packet less than half the size. ??

BTW, I changed it back and forth to insure it was not a one-time thing.

[Reply #267 on:]

Maybe there is some historical significance to that number.

I dunno. Maybe the original router had 1.5k of RAM and they needed 36 bytes for variables so that left 1500, the original spec. Then along came somebody else who needed another 8 bytes for something else so it became 1492.

But there is another reason for this post. After some experimenting this morning, I found an interesting phenomenon.

It makes sense if you think about it.

If you're writing big packets the W5100 has to wait for the data to arrive and the ACK packet to come back before it can free up enough space for you to write another packet. That take milliseconds (hundreds of milliseconds across the Internet) and you're sitting idle all that time.

If you're writing small packets then you can start uploading more data instantly after each SEND command. The round trip needed for SEND/ACK doesn't affect you nearly so much.

[Reply #268 on:]

So I'm still getting lock ups about every 3 days or so.  I can't figure out what is going on.  This thread seems to have died.  Are you guys still trying to figure out what is going on?  OR was it resolved and I missed it?

Thanks!

[Reply #269 on:]

I think fungus got his problem worked out by limiting the packet size. I can't create the failure after I disabled the microSD card reader's SPI interface. You should mention if it is a client or server program that is failing. You might do better starting a new thread.