RE: [lwip-users] performance in sending / receiving + tcp_tmr

[Taranowski, Thomas \(SWCOE\)]

I'm not really familiar with the playstation 2 kernel, but it seems like
you would be able to access the scheduling history of the kernel, and
view it somehow (hopefully with a nice GUI interface).  It might be
interesting to see how your threads are being scheduled.  It almost
sounds like the highest priority thread is starving out all of your
lower priority threads.

In regards to the tcp timer thread...
I was under the assumption that, when tcpip_init() was called, it
started one of the internal lwIP timers to act as the tcp timer.  

In one of my first port implementations, I was calling tcpip_init(),
then starting a timer thread which called tcp_tmr() periodically.
However, I saw  that tcpip_init() spawns the tcpip_thread, which calls
tcp_init, which calls tcpip_tcp_timer, which basically calls tcp_tmr at
regular intervals.  This was doing the same thing as my timer thread,
which periodically called the tcp_tmr() routine.  

In essence I was calling tcp_tmr() at twice the rate at which it was
needed, and who knows what other effect it was having.  Once I removed
the timer thread, tcp started acting normally again and life was good.

It sounds like you might be running into the same issue I faced, with
tcp_tmr being called at double the rate.  Once from inside the lwIP
tcpip thread, and once from the timer thread.  Of course, I could be
totally misunderstanding everything, in which case I hope someone sets
me straight.

-Tom


> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
On
> Behalf Of Robert Goeffringmann
> Sent: Thursday, February 15, 2007 7:03 AM
> To: Mailing list for lwIP users
> Subject: Re: [lwip-users] performance in sending / receiving
> 
> Hi Kieran,
> I'm sorry for the delay in getting back to you, I've been busy with
exams
> lately. :/
> 
> > Having had a look at your ethereal captures I see it advertising up
to
> > around 42KB.  A full capture (from the start of a connection) in
pcap
> > rather than txt format would enable me to look at this more
precisely.
> 
> > Actually, in this case (with the benefit of looking at your packet
> > capture) it looks like the stack is processing the packets at a
> > reasonable rate (the ACK numbers are increasing) but the window is
still
> > decreasing.  This suggests that the packets are being buffered in
the
> > sockets API layer, and the application is not reading them fast
enough.
> > ie. This could be a scheduling issue.
> 
> That'd make sense.
> The PS2 kernel doesn't do any automatic scheduling, it'll simply
execute
> the
> thread with the highest priority which is not waiting for a semaphore
or
> messagebox at the moment.
> 
> right now I have the threads structured like this (highest to lowest
> priority):
> 
> - highest priority is the thread for the HW interface, it takes lwip's
> packets from a queue and passes them to the HW (or reads them from the
HW
> and passes them to lwip...)
> - the next thread is the timer thread, which only calls tcp_tmr and
> etharp_tmr periodically
> - then there's lwip's tcp/ip thread
> - and the lowest thread is the application doing the the send/recv
calls.
> 
> This structure has worked pretty well for sending data, but indeed it
did
> seem to cause those zero-windows.
> I've changed it and made the tcp/ip thread the one with the lowest
> priority
> and it fixed that... but unfortunately it has rather little influence
on
> the
> receive speed.
> With the application having the lowest priority, I had transfer rates
of
> ~1,6MB/s (average), with the actual transmission speed varying between
1,3
> and 2,0 MB/s.
> If the tcp/ip thread has the lowest priority, the average speed is
> ~1,8MB/s,
> varying between 1,0 and 1,9 MB/s.
> 
> I uploaded the pcap files and lwip's statistics here:
> http://www.goeffringmann.de/lwip/thprio.zip
> 
> the prio1 file is the one with the application having the lowest
priority,
> in prio50 it's the tcp/ip thread.
> 
> Is there anything like a suggested model for those thread priorities?
> 
> I also wrote a checksum routine in assembly, but no matter if I use
that
> one
> or lwip's most basic one doesn't have any difference at all on either
> sending- or receiving speed. So I suppose I can assume that cpu power
is
> not
> the bottleneck... right?
> 
> Thanks a lot for your help,
> 
> Robert.
> 
> 
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users