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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
