Kieran Mansley wrote:
>
> This is exactly what I was thinking from looking at the packet captures.
> My guess is tcp_tmr() is being called at a way-out-of-specification
> frequency.
>
Thank you very much Simon, Kieran
after fixing the convertion of ticks in ms in the ecos code my application
wo
On Mon, 2012-07-02 at 17:39 +0200, Simon Goldschmidt wrote:
> , it actually seems that your TCP timer is running way too fast.
> Please ensure it is configured to run every 250ms and that this timing
> actually works (e.g. by toggeling an IO pin of your target from
> tcp_tmr()).
This is exactly wh
Fred39 wrote:
> LWIP is the slave which response!
Just to rule out any uncertainties, this would be 192.168.0.222 in your
captures (that would be the info requested, simply put)?
In that case, how can you change the tcp timer interval of the master? Or isn't
that what you did?
> http://old.na
I hate it when I'm trying to be helpful and I'm just wrong. But I
subscribed also to learn, and that is one of the advantages of a forum
like this. Thanks for the corrections!
Regarding the traffic direction, the email archive here
http://old.nabble.com/Retransmission-behaviour--td34077302.html
Kieran Mansley wrote:
>
> I'm also hoping you'll tell us which end is lwIP and which end is not as
> without that it will be impossible to diagnose the failure.
>
Hi Kieran
LWIP is the slave which response!
http://old.nabble.com/file/p34102440/master2sec.pcap master2sec.pcap
http://old.nab
On Mon, 2012-07-02 at 15:41 +0100, Kieran Mansley wrote:
> Simon's right. The estimation of the RTO though may be (i) measured
> in
> slow timer ticks; and (ii) potentially much less than 1 slow timer
> tick.
> In these cases the stack will wait for exactly TCP_TMR_INTERVAL. In
> cases where the
On Thu, 2012-06-28 at 22:59 -0700, Fred39 wrote:
> Kieran Mansley wrote:
> >
> > A packet capture would be helpful too to get the timings.
> >
> http://old.nabble.com/file/p34089788/packet1ms.png packet1ms.png
> Good Morning Guys
>
> so i put 2 captures
> http://old.nabble.com/file/p34089788/pa
On Mon, 2012-07-02 at 15:23 +0200, Simon Goldschmidt wrote:
> "Pomeroy, Marty" wrote:
> > > The TCP_TMR_INTERVAL is the time the stack should wait for an ACK from
> > my master, right?
> >
> > Yes, before it re-transmits.
>
> Is that so? I would have thought that slow-retransmission depends on
"Pomeroy, Marty" wrote:
> > The TCP_TMR_INTERVAL is the time the stack should wait for an ACK from
> my master, right?
>
> Yes, before it re-transmits.
Is that so? I would have thought that slow-retransmission depends on the
connection's RTO (which is normally an order of magnitude slower than
> The TCP_TMR_INTERVAL is the time the stack should wait for an ACK from
my master, right?
Yes, before it re-transmits.
> What is akward to me is that after the retransmission of LWIP which
happends in 30-40ms after the first response, the ACK for the response
arrives 1ms after the retransmissi
Fred39 wrote:
> I know that you are criticizing me but i am new to this field and hope you
> have understanding for it
That wasn't criticism. I haven't really followed this thread, but it seemed
like you had changed the TCP timer interval, which is normally not a good idea
since it leads to mor
Simon Goldschmidt wrote:
>
> Generally, this is a value which you should only change if you really,
> really know what you are doing and know the consequences of that change.
>
Simon
The TCP_TMR_INTERVAL is the time the stack should wait for an ACK from my
master, right?
So my problem is that
Fred39 wrote:
> My Questions are:
> Would this crash the system in future if the TCP_TMR_INTERVAl is set so
> high? What would happen if i dont use the tcpip_tcp_timer in a longtme
> runing system?
You should not need to change the interval of the TCP timers in the first
place. Why do you think
Good morning and a good start in the week LWIP users :)
Kieran suggestion is true. The other ends delayed ACK timer should time out
and send a ACK so there shouldn't be a retransmission. But this is not
happening.
My suggestion is:
- When i set the master fast like i said before 1ms it also sen
Kieran Mansley wrote:
>
> A packet capture would be helpful too to get the timings.
>
http://old.nabble.com/file/p34089788/packet1ms.png packet1ms.png
Good Morning Guys
so i put 2 captures http://old.nabble.com/file/p34089788/packet2sec.png
packet2sec.png
one shows the trace when the master
Kieran Mansley wrote:
>
> A packet capture would be helpful too to get the timings.
>
http://old.nabble.com/file/p34089786/packet1ms.png packet1ms.png
Good Morning Guys
so i put 2 captures http://old.nabble.com/file/p34089786/packet2sec.png
packet2sec.png
one shows the trace when the master
On Thu, 2012-06-28 at 11:09 -0400, Pomeroy, Marty wrote:
> But in any case, I think the behavior is normal.
No, it's not normal. The other end's delayed ACK timer should time out
and send an ACK before the retransmission timer times out and sends the
retransmission. If we know which end is lwIP
> But if i set the cycle time of the master slow, like 80ms and slower i
> get an response and a retransmission of that response for every
request.
> request ->
> <- response
> <- retransmission
Which end is lwIP?
Kieran
I'm assuming the response/retransmission is from lwIP. Hoping I
> How can i fix this issue? Would you guys say it is a Stack specific
problem?
Fred
What "issue" do you see? Your postings so far have been clear enough
about what was sent and received, although AFAICT have shown expected
behavior for TCP/IP.
Please post the send-receive pattern you think
On Wed, 2012-06-27 at 01:14 -0700, Fred39 wrote:
> But if i set the cycle time of the master slow, like 80ms and slower i get
> an response and a retransmission of that response for every request.
> request ->
> <- response
> <- retransmission
Which end is lwIP?
Kieran
__
Ok I found out by raising the #define TCP_TMR_INTERVAL very high like 2
reduces the retransmission. What now appears is that retransmission comes in
a specific interval depending on the TCP_TMR_INTERVAL.
How can i fix this issue? Would you guys say it is a Stack specific problem?
I saw this
Hi Marty
sorry i maybe should have told more about the transfer.
Pomeroy, Marty wrote:
>
> Your reponse needs to be acknowledged, and the acknowledgment (Ack) for
> your previous response is included in the next request.
>
Yes this i can confirm when the master Cylce is very fast i found o
But if i set the cycle time of the master slow, like 80ms and slower i
get an response and a retransmission of that response for every request.
request ->
<- response
<- retransmission
Fred
Your reponse needs to be acknowledged, and the acknowledgment (Ack) for
your previous response is in
Hi Lwip Users
i am facing a problem and cant find a solution. I have a master slave
application which uses tcp protocol. I get a request and reponse to it. If i
put the master cylce time very fast (send request every 1 ms)the
transmission looks ok
request ->
<- response
request ->
<- respo
24 matches
Mail list logo
