So in "A" I do many client.print() calls, and it takes 14 ms to send all 6 sensor values.

In "B" I collect the whole response in a single String, and send this string out over ethernet.Wow - It takes much longer now !?!?!? It needs 33 ms. So the String class may be bad? Or the analogReads all much more back-to-back compared to "a" ?

But no - in "C" I use the String class too, and collect all sensor values back-to-back too, but I just don't send it out over Ethernet - and it takes only 5 ms!!

Isn't this just telling you that client.println() consumes some time, but that once it's sent to the ethernet shield, the shield will put it on the wire in parallel to other activities. So you can be reading analog and accumulating data for your next print. Your B version waits until the end to send ~120 chars. A version takes advantage of the parallelism, C version tells you client.println() takes a while.

Isn't this just telling you that client.println() consumes some time, but that once it's sent to the ethernet shield, the shield will put it on the wire in parallel to other activities.

No, I am sorry this can not explain the timings: In "C" we see, that the collection of the whole response takes 5 ms. But the only difference to "B" is, that B sends out this string via Ethernet. As B needs 33 ms, and the first part (equals to C) takes only 5 ms, the sending via ethernet needs 28 ms in "B". But this is much more than the whole thing (including sending out everything over ethernet) takes only 14 ms in "A".

Have you tried your speed test using client.write()? I use the write function not documented in the manual. It seems to perform pretty good. I have not tested it tho. I load everything up into outBuffer of size bufferSize, then send it in one call.

String response111 = String("");Please explain this statement. Construct a string object containing no characters. Then, use the assignment operator to set another string to that copy. Then, delete the string object.

No I have not by now, but it seems a good idea. Even more, as just found out (with tcpdump), that in variant "A" each digit of each sensor value comes in its own ethernet package, and even worse: In variant "B" each single letter (!!!) comes in its own ethernet package.

@PaulS: Stupid is, who looks for microseconds, when milliseconds are in question.

I am surprised at the result of variant B. I thought it would go in one packet.

Please let me know how the write function does in comparison. I know that client.write(byte)sends each byte in a packet, but according to my router, that dropped to a single packet by usingclient.write(byte*,int);

ADD: You might want to try another variant of write in variant B. Try replacingclient.println(response1111);withclient.write(response1111);

That does the same as my client.write() above, actually this:client.write(response1111,strlen(response1111));

The client.write(byte*,int) sends all the characters in the byte array to the w5100 transmit buffer, then sends the w5100 the "send" command. That should send all that in one packet. Should...

Just a warning about sprintf(), since you may soon want to convert int to float for voltage and the like.There is no %f parameter. sprintf will not convert a float to a string.But you can convert them:http://arduino.cc/forum/index.php/topic,72682.0.html

Just a warning about sprintf() ... There is no %f parameter. sprintf will not convert a float to a string.

Oh. Thanks for the hint, may be it saves me some headache later on.

BTW: A brief SUMMARY on the thread issue:

- don't use client.print(stringObject) !! (as of arduino version 22) It will send each letter in its own ethernet package. (Maybe the client.print method should be extended to handle stringObjects in a appropriate way)

- the new timings still may not be, what someone might expect from a 10 Mbit/s connection. But this is not a bug, but due to the SPI speed limitation, as the ethernet shield is connected via SPI.