Pages: 1 [2] 3   Go Down
Author Topic: Ethernet cleint println() makes new packet every time  (Read 2648 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Newbie
*
Karma: 0
Posts: 42
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thank you. It helps a lot! smiley
So, the next question is how could I overcome this ~40 seconds try? Or at least how can I make it not occupy all Arduino resources? I have a program on the Arduino that needs to run smooth, no matter if there's connection to the server.
Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 42
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Anyone any idea or hint?
Logged

Seattle, WA USA
Online Online
Brattain Member
*****
Karma: 642
Posts: 50398
Seattle, WA USA
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Or at least how can I make it not occupy all Arduino resources?
The wording of this question implies a lack of understanding of the Arduino. The question implies that the thread that is waiting for a connection is block all other threads. Well, that is both true and false. It is false in the sense that there are no other threads to block. It is true in the sense that the connect function is indeed blocking the (only) thread.

Changing the connect function will require a thorough understanding of all of the code involved in creating (and waiting for) the connection. You will most likely need to change the number of times the code tries to connect, and the amount of time it waits for a connection.

Either of these changes will reduce the likelihood of a successful connection. So, you'll need to compensate for this, somehow.
Logged

0
Offline Offline
Newbie
*
Karma: 0
Posts: 42
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well, I know pretty well Arduino isn't C#, Java or similar managed code language smiley-wink
However, I thought there is a nice solution about this. Arduino is very popular platform to connect to pachube and other services and this "freezing" if there's no server is no good.
Logged

0
Offline Offline
Tesla Member
***
Karma: 145
Posts: 9698
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
So, the next question is how could I overcome this ~40 seconds try? Or at least how can I make it not occupy all Arduino resources?

Have you looked in the ethernet library to see if there are some default time settings that can be changed?
Logged

Consider the daffodil. And while you're doing that, I'll be over here, looking through your stuff.   smiley-cool

Dallas, Texas
Offline Offline
Sr. Member
****
Karma: 3
Posts: 267
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

The max TCP size packet is ~1500 bytes, you don't want a buffer that big.

Technically, TCP has no such limitation. That's an ethernet limitation which jumbo frame ethernet works around.
Logged


0
Offline Offline
Newbie
*
Karma: 0
Posts: 42
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Have you looked in the ethernet library to see if there are some default time settings that can be changed?

Yes, I've looked there. There's no such parameters.
Logged

Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 224
Posts: 13915
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Quote from: robtillaart on July 20, 2011, 05:52:51 PM
The max TCP size packet is ~1500 bytes, you don't want a buffer that big.

Technically, TCP has no such limitation. That's an ethernet limitation which jumbo frame ethernet works around.
OK gerg, you are technically absolutely right, but please read the - http://en.wikipedia.org/wiki/Jumbo_frame#Adoption - section carefully (esp. line 1).

Jumbo frames can support up to 9K but implementations may differ. It is mostly used in gigabit range in special subnets. Furthermore there are investigations for 64K packets and even beyond that. But all these are not suitable in "Arduino land" where 2K RAM is all the RAM you got. Even a MEGA with its 8K can't allocate a jumbo frame. I don't know the specs of the standard ethernet chips W5100 and ENC28J60 but I doubt if they support the jumbo frames.

Rob
Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

Dallas, Texas
Offline Offline
Sr. Member
****
Karma: 3
Posts: 267
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I don't believe I made a jumbo frame recommendation. I was simply pointing out the 1500 byte limitation stems from ethernet, not TCP; and extensions to ethernet exist specifically to work around such limitations. Different transports commonly have different MTUs. Use of TCP is agnostic about the underlying transport, especially considering it (IP actually) will happily fragment the packets based on MTU, so as to make it to the end point.

Its also worth pointing out ethernet is not the sole transport for IP. Various transports can have a variety of MTUs. Many times the MTU is smaller than 1500. So regardless of how you choose to use TCP, you should not be making any assumptions of 1500-bytes, or otherwise.
Logged


Global Moderator
Netherlands
Offline Offline
Shannon Member
*****
Karma: 224
Posts: 13915
In theory there is no difference between theory and practice, however in practice there are many...
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Sorry gerg, I misinterpreted your post, you are right. I have worked with SLIP and PPP over serial lines so I should have known better  smiley-red

Rob

Logged

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

0
Offline Offline
Newbie
*
Karma: 0
Posts: 42
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

That's interesting stuff, guys. However do you have any idea how Ethernet library could be tweaked to work with less waiting time for server response? Or even not to wait for server responce at all, like UDP. I need my software to run smooth, no matter if there's server to listen. The only idea that comes to my mind is to use another Atmega 328 just for Ethernet communication, but I would like to try every other option out there, before do that.
Logged

Dallas, Texas
Offline Offline
Sr. Member
****
Karma: 3
Posts: 267
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

That's interesting stuff, guys. However do you have any idea how Ethernet library could be tweaked to work with less waiting time for server response?

Can you better define what that means?

Or even not to wait for server responce at all, like UDP. I need my software to run smooth, no matter if there's server to listen. The only idea that comes to my mind is to use another Atmega 328 just for Ethernet communication, but I would like to try every other option out there, before do that.

Keep in mind UDP/IP and TCP/IP both provide different capabilities and features. Specifically, what features are you finding attractive? Is it that UDP is connectionless whereas TCP is connection orientated? I think that's what you're describing but I'm not really sure.

Can you describe the features you desire and the features you don't like about TCP. What is your application? What does it do? How important is it the data actually arrive at the destination?

Logged


0
Offline Offline
Newbie
*
Karma: 0
Posts: 42
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Keep in mind UDP/IP and TCP/IP both provide different capabilities and features. Specifically, what features are you finding attractive? Is it that UDP is connectionless whereas TCP is connection orientated? I think that's what you're describing but I'm not really sure.

Can you describe the features you desire and the features you don't like about TCP. What is your application? What does it do? How important is it the data actually arrive at the destination?

Hi Greg,
I make a five zone thermostat device that is controlled via TCP/IP and HTTP REST as application layer protocol. Every two seconds one zone status is sent to a server via HTTP REST, so in 10 seconds all 5 zones are sent (this short timing is not necessary, so I plan to send a zone status each 12 seconds). A zone status means the temperature, the humidity, the temperature setpoint and a status of the heater. Beside this, every time a new setpoint is set from the device, it sends immediately update to the server.

I don't need to know if the data arrived successfully to the server. This thermostat is going to work on a local network and even if the packet failed, a new zone status is going to send after a few seconds.

On the other hand, I need this device to work properly even there's no connection to the server. The Ethernet control and monitoring is just an additional (secondary) feature. It's primary feature is to work as a normal dumb thermostat and do it right, no matter if it can send data to a server.

Hope this info helps smiley
Logged

Wellington, New Zealand
Offline Offline
Sr. Member
****
Karma: 1
Posts: 404
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I don't see why the library needs to block while the TCP connection is being made, but after a quick look at how the ethernet library is working it looks like it would need to be redesigned to not busy wait for the w5100 to finish executing commands.

E.g. Client::connect() calls socket.cpp:connect(), which calls W5100.execCmdSn(), which sends the connect command to the w5100 and busy waits for the w5100 to complete the operation (or give up after a timeout period).

Code:
void W5100Class::execCmdSn(SOCKET s, SockCMD _cmd) {
  // Send command to socket
  writeSnCR(s, _cmd);
  // Wait for command to complete
  while (readSnCR(s))
    ;
}

You could try reducing the timeout period by adjusting the w5100 RTR and RCR registers.

An option that wouldn't require a complete rewrite of the library would be to make a custom connect() command that sends the connect command to the w5100 but returns immediately without waiting for it to complete, and an accompanying connect_status() command that lets your sketch manually check to see if the connect operation has completed and check the result of the command.  Just take care to not try any other ethernet operations until the connect has completed.

« Last Edit: August 02, 2011, 06:12:46 am by dhunt » Logged


0
Offline Offline
Newbie
*
Karma: 0
Posts: 42
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi, dhunt and thank you for this nice answer.

I already have traced the connect() method to execCmdSn() of the W5100Class and already tested some dirty hacks to overcome this issue. For example I have commented this:
Code:
while (readSnCR(s))
    ;
However nothing changed.

Quote
You could try reducing the timeout period by adjusting the w5100 RTR and RCR registers.
Where could I find these registers? And what they do?
Logged

Pages: 1 [2] 3   Go Up
Jump to: