From: <hin...@ce...> - 2006-10-20 09:12:32
|
Hello all, I'm testing two IrDA modules - SMSC IRCC2 and Moschip MCS7780. SMSC=20 linux kernel driver is already in kernel source tree, while Moschip=20 driver can be found at https://projects.cecs.pdx.edu/svn/mcs7780. I've managed to enable SMSC on my COMPAQ Neo notebook and MCS7780 is=20 connected to the other machine as USB device. For testing I used IRcomm=20 protocol. I've setup PPP connection between the two machines via IrDA ports at=20 4Mbps. I'm transfering 1M data file from one machine to another using=20 ftp over the IrDA PPP link. What concerns me is the speed of transfer. On my setup transfer in one=20 direction is far greater then transfer in another direction. Eg. getting=20 file from the host with smsc IrDA is very fast (approx 350KB/s), while=20 putting file to the host with smsc IrDA is very slow (approx 10 KB/s). HOST1: - modprobe smsc_ircc2 - irattach irda0 -s - pppd /dev/ircomm0 115200 local noauth debug kdebug 7 nodetach HOST2: - insmod mcs7780.ko - irattach irda0 -s - pppd noauth debug kdebug 7 nodetach 115200 local /dev/ircomm0 192.168.5.5:192.168.5.6 Transfer: - on HOST2 I start ftp session toward HOST1 (ftp 192.168.5.6) HOST1 -> HOST2 - get test_1M Transfer of 1M random data file takes about ~3 sec in this direction. irdadump log: Note the time between two frames here is very small! ... 12:44:42.192235 i:rsp > ca=3Dd4 pf=3D0 nr=3D5 ns=3D6 LM slsap=3D33 dlsap= =3D66 (1523) 12:44:42.195091 i:rsp > ca=3Dd4 pf=3D0 nr=3D5 ns=3D7 LM slsap=3D33 dlsap= =3D66 (1527) 12:44:42.199080 i:rsp > ca=3Dd4 pf=3D1 nr=3D5 ns=3D0 LM slsap=3D33 dlsap= =3D66 (1522) 12:44:42.203139 i:cmd < ca=3Dd4 pf=3D0 nr=3D1 ns=3D5 LM slsap=3D66 dlsap= =3D33 (62) 12:44:42.203406 i:cmd < ca=3Dd4 pf=3D1 nr=3D1 ns=3D6 LM slsap=3D66 dlsap= =3D33 (62) 12:44:42.203452 i:rsp > ca=3Dd4 pf=3D0 nr=3D7 ns=3D1 LM slsap=3D33 dlsap= =3D66 (2044) 12:44:42.207129 i:rsp > ca=3Dd4 pf=3D1 nr=3D7 ns=3D2 LM slsap=3D33 dlsap= =3D66 (1003) 12:44:42.211154 i:cmd < ca=3Dd4 pf=3D0 nr=3D3 ns=3D7 LM slsap=3D66 dlsap= =3D33 (62) 12:44:42.211425 i:cmd < ca=3Dd4 pf=3D1 nr=3D3 ns=3D0 LM slsap=3D66 dlsap= =3D33 (62) 12:44:42.211471 i:rsp > ca=3Dd4 pf=3D0 nr=3D1 ns=3D3 LM slsap=3D33 dlsap= =3D66 (1527) 12:44:42.215299 i:rsp > ca=3Dd4 pf=3D0 nr=3D1 ns=3D4 LM slsap=3D33 dlsap= =3D66 (1526) 12:44:42.219105 i:rsp > ca=3Dd4 pf=3D0 nr=3D1 ns=3D5 LM slsap=3D33 dlsap= =3D66 (1519) 12:44:42.223087 i:rsp > ca=3Dd4 pf=3D1 nr=3D1 ns=3D6 LM slsap=3D33 dlsap= =3D66 (1514) 12:44:42.227212 i:cmd < ca=3Dd4 pf=3D0 nr=3D7 ns=3D1 LM slsap=3D66 dlsap= =3D33 (62) 12:44:42.227465 i:cmd < ca=3Dd4 pf=3D0 nr=3D7 ns=3D2 LM slsap=3D66 dlsap= =3D33 (62) 12:44:42.231135 i:cmd < ca=3Dd4 pf=3D1 nr=3D7 ns=3D3 LM slsap=3D66 dlsap= =3D33 (62) 12:44:42.231182 i:rsp > ca=3Dd4 pf=3D0 nr=3D4 ns=3D7 LM slsap=3D33 dlsap= =3D66 (1526) 12:44:42.235038 i:rsp > ca=3Dd4 pf=3D0 nr=3D4 ns=3D0 LM slsap=3D33 dlsap= =3D66 (1525) 12:44:42.235340 i:rsp > ca=3Dd4 pf=3D0 nr=3D4 ns=3D1 LM slsap=3D33 dlsap= =3D66 (2044) ... HOST2 -> HOST1 - put test_1M Transfer of 1M random data file takes about ~160 sec in this directio= n. irdadump log: Note the time between two frames here is larger in contrast to transfer=20 above. ... 12:46:53.879202 rr:cmd < ca=3Dd4 pf=3D1 nr=3D2 (2) 12:46:53.879246 i:rsp > ca=3Dd4 pf=3D1 nr=3D5 ns=3D2 LM slsap=3D33 dlsap= =3D66 (62) 12:46:53.883426 i:cmd < ca=3Dd4 pf=3D1 nr=3D3 ns=3D5 LM slsap=3D66 dlsap= =3D33 (1004) 12:46:53.883489 rr:rsp > ca=3Dd4 pf=3D1 nr=3D6 (2) 12:46:53.891268 i:cmd < ca=3Dd4 pf=3D0 nr=3D3 ns=3D6 LM slsap=3D66 dlsap= =3D33 (2044) 12:46:54.695254 rr:cmd < ca=3Dd4 pf=3D1 nr=3D3 (2) 12:46:54.695301 i:rsp > ca=3Dd4 pf=3D0 nr=3D7 ns=3D3 LM slsap=3D33 dlsap= =3D66 (62) 12:46:54.699298 i:rsp > ca=3Dd4 pf=3D1 nr=3D7 ns=3D4 LM slsap=3D33 dlsap= =3D66 (62) 12:46:54.703297 i:cmd < ca=3Dd4 pf=3D1 nr=3D5 ns=3D7 LM slsap=3D66 dlsap= =3D33 (1009) 12:46:54.703367 rr:rsp > ca=3Dd4 pf=3D1 nr=3D0 (2) 12:46:54.707345 i:cmd < ca=3Dd4 pf=3D0 nr=3D5 ns=3D0 LM slsap=3D66 dlsap= =3D33 (1519) 12:46:55.511325 rr:cmd < ca=3Dd4 pf=3D1 nr=3D5 (2) 12:46:55.511375 i:rsp > ca=3Dd4 pf=3D0 nr=3D1 ns=3D5 LM slsap=3D33 dlsap= =3D66 (62) 12:46:55.515350 i:rsp > ca=3Dd4 pf=3D1 nr=3D1 ns=3D6 LM slsap=3D33 dlsap= =3D66 (62) 12:46:55.519389 i:cmd < ca=3Dd4 pf=3D1 nr=3D7 ns=3D1 LM slsap=3D66 dlsap= =3D33 (1514) ... If I try the reverse - ftp from HOST1 to HOST2 the same can be observed,=20 only that direction of transfer is reversed (slow transfer on get, and=20 fast transfer on put). How can I solve the issue? I've tried changing minimum turnaround time=20 from 1ms to 0ms and 5ms, but with no avail. Any help is appreciated! Best regards, hinko --=20 =C4=8CETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: hin...@ce... Http: www.cetrtapot.si |
From: Alan J. M. <ala...@ya...> - 2006-10-23 21:31:32
|
In article news:453...@ce..., hin...@ce... wrote: [...] > What concerns me is the speed of transfer. On my setup transfer in one > direction is far greater then transfer in another direction. Eg. > getting file from the host with smsc IrDA is very fast (approx > 350KB/s), while putting file to the host with smsc IrDA is very slow > (approx 10 KB/s). > [...] > How can I solve the issue? I've tried changing minimum turnaround time > from 1ms to 0ms and 5ms, but with no avail. > Three questions/comments. Has all the testing been done with one machine alone as the IrDA Primary (i.e. the machine that did the IrDA discovery and started the connection)? That's what the traces you've included appear to show. That could be the cause of the asymmetric behaviour that you're seeing. Hopefully this wouldn't be too hard for you to verify. I'm expecting that to be the most interesting, but here's some other thoughts. Can you do a test just with IrDA traffic? Removing any possibility that the speed difference is due to bad interaction between the behaviour / arrival rates of TCP and IrDA. For instance it could be that one end has data to send but the other end isn't ceding the half-duplex link. I note that there are two instances where the inter frame gap is 0.8s. Not in quite the same range of Minimum Turnaround Time! :-) 800 times bigger in fact. What's the Maximum Turnaround Time value in effect? Maybe reducing that might help, causes the half-duplex link to swap over more often. Note that in both cases after the 800ms delay the next frame from the opposite end comes immediately. I don't think its happening but are there any frame drops/errors occuring. For instance if you run irdadump on both ends do you get the same sequence of frames, with no retransmissions occuring? -- Alan J. McFarlane http://www.alanjmcf.me.uk/ Please follow-up in the newsgroup for the benefit of all. |
From: <hin...@ce...> - 2006-11-13 11:30:22
|
Hello, I've been very busy last few days, so I didn't manage to test the things you wrote before. Her goes. Alan J. McFarlane wrote: >=20 > Has all the testing been done with one machine alone as the IrDA Primar= y=20 > (i.e. the machine that did the IrDA discovery and started the=20 > connection)? That's what the traces you've included appear to show.=20 > That could be the cause of the asymmetric behaviour that you're seeing.= =20 > Hopefully this wouldn't be too hard for you to verify. I've additionally tested both cases: Where each machine takes primary role once, and the other is the only one as secondary. What happens is next: 1) When MCS7780 is acting as primary (sends SNRM) and SMSC-IIRC2 acts as=20 secondary (responds with UA), transferring file from primary to=20 secondary is very,very slow (few kBs). Here primary acts as sender and=20 sends the data in cmd packets for secondary to receive. Transfering file from secondary to the primary is approx. ten times=20 faster (about ~40 - 70 kBs). Here primary is receiving data in rsp=20 packets from secondary. 2) When SMSC-IIR2 is acting primary (sends SNRM) and MCS7780 is acting=20 as secondary (responds with UA), transferring files from primary to=20 secondary is very,very fast (~330kBs)! Here primary is acting as sender=20 and sends the data to the secondary in cmd packets for secondary to recei= ve. Transferring file from secondary to the primary is as slow as in case=20 1), where MCS7780 as primary sends the data to the SMSC-IIRC2 as=20 secondary (few < 10 kBs). Here primary is receiving data in rsp packets=20 from secondary. >=20 > I'm expecting that to be the most interesting, but here's some other > thoughts. >=20 > Can you do a test just with IrDA traffic? Removing any possibility tha= t > the speed difference is due to bad interaction between the behaviour / > arrival rates of TCP and IrDA. For instance it could be that one end > has data to send but the other end isn't ceding the half-duplex link. I've testing using ppp connection in the past, but for these test today,=20 I've used minicom and its file sending feature (zmodem). Now that TCP is=20 out of the way, I can say that similar was observed when using ppp+ftp=20 for test, as now when using only minicom (on top of IrCOMM). Transfer=20 speeds are more-or-less the same, so I think we can rule out the fact=20 that upper levels might be the problem. >=20 > I note that there are two instances where the inter frame gap is 0.8s. > Not in quite the same range of Minimum Turnaround Time! :-) 800 times > bigger in fact. What's the Maximum Turnaround Time value in effect? Maximum turnaround time is set to 500ms. I've tried less, but ircomm=20 kernel driver hard codes this to 500ms even if user supplied value=20 should be used, during driver init. I'll try other turnaround times for the link and comment later. > Maybe reducing that might help, causes the half-duplex link to swap ove= r > more often. Note that in both cases after the 800ms delay the next > frame from the opposite end comes immediately. Yes, its strange that once the 0.8 s 'pause' is over the transmitter is=20 always ready to send more data (if available). It tells me (as it seems)=20 that for some reason station changes transfer direction while it has=20 nothing to send - so it just holds the link for max_turn_time and then=20 releases it to the other side once timer reaches 500ms. Why or how and=20 when this would happen is not known to me... Just a guess. I've been looking at the ethereal and irdadumps and one interesting=20 thing is that SMSC-IIRC2 only provide 3 frame window, wile MCS7780 can=20 handle 7 frames window. That being said, I've noticed, that in the case where data is sent from=20 SMSC-IIRC2 (primary) station to the MCS7780 (secondary) station,=20 secondary station ACKs every seventh frame (irdadump on secondary): ... 09:42:44.698221 i:rsp > ca=3Db4 pf=3D1 nr=3D0 ns=3D2 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D8 (5) 09:42:44.702195 i:cmd < ca=3Db4 pf=3D0 nr=3D3 ns=3D0 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1063) 09:42:44.705192 i:cmd < ca=3Db4 pf=3D0 nr=3D3 ns=3D1 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1055) 09:42:44.707188 i:cmd < ca=3Db4 pf=3D0 nr=3D3 ns=3D2 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1067) 09:42:44.712194 i:cmd < ca=3Db4 pf=3D0 nr=3D3 ns=3D3 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (2044) 09:42:44.713200 i:cmd < ca=3Db4 pf=3D0 nr=3D3 ns=3D4 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (85) 09:42:44.715186 i:cmd < ca=3Db4 pf=3D0 nr=3D3 ns=3D5 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1062) 09:42:44.718189 i:cmd < ca=3Db4 pf=3D1 nr=3D3 ns=3D6 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1067) 09:42:44.718219 i:rsp > ca=3Db4 pf=3D1 nr=3D7 ns=3D3 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D8 (5) 09:42:44.722189 i:cmd < ca=3Db4 pf=3D0 nr=3D4 ns=3D7 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1065) 09:42:44.725192 i:cmd < ca=3Db4 pf=3D0 nr=3D4 ns=3D0 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1067) 09:42:44.727189 i:cmd < ca=3Db4 pf=3D0 nr=3D4 ns=3D1 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1061) 09:42:44.732193 i:cmd < ca=3Db4 pf=3D0 nr=3D4 ns=3D2 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (2044) 09:42:44.733203 i:cmd < ca=3Db4 pf=3D0 nr=3D4 ns=3D3 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (80) 09:42:44.735186 i:cmd < ca=3Db4 pf=3D0 nr=3D4 ns=3D4 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1058) 09:42:44.738187 i:cmd < ca=3Db4 pf=3D1 nr=3D4 ns=3D5 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1064) 09:42:44.738220 i:rsp > ca=3Db4 pf=3D1 nr=3D6 ns=3D4 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D8 (5) 09:42:44.742190 i:cmd < ca=3Db4 pf=3D0 nr=3D5 ns=3D6 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1060) 09:42:44.745192 i:cmd < ca=3Db4 pf=3D0 nr=3D5 ns=3D7 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1059) 09:42:44.747191 i:cmd < ca=3Db4 pf=3D0 nr=3D5 ns=3D0 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1063) 09:42:44.752193 i:cmd < ca=3Db4 pf=3D0 nr=3D5 ns=3D1 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (2044) OTOH, when data is sent from MCS7780 (still secondary) station to the=20 SMSC-IIR2 station (primary), primary station ACKs every third frame=20 (irdadump on secondary): ... 09:47:33.845079 rr:cmd < ca=3Db4 pf=3D1 nr=3D3 (2) 09:47:33.845105 i:rsp > ca=3Db4 pf=3D1 nr=3D7 ns=3D3 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (93) 09:47:33.847075 i:cmd < ca=3Db4 pf=3D1 nr=3D4 ns=3D7 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D8 (5) 09:47:33.847102 i:rsp > ca=3Db4 pf=3D0 nr=3D0 ns=3D4 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1056) 09:47:33.849074 i:rsp > ca=3Db4 pf=3D0 nr=3D0 ns=3D5 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1067) 09:47:33.851075 i:rsp > ca=3Db4 pf=3D1 nr=3D0 ns=3D6 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1067) 09:47:33.856077 rr:cmd < ca=3Db4 pf=3D1 nr=3D5 (2) 09:47:33.856103 i:rsp > ca=3Db4 pf=3D0 nr=3D0 ns=3D5 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1067) 09:47:33.858076 i:rsp > ca=3Db4 pf=3D1 nr=3D0 ns=3D6 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1067) 09:47:34.353053 rr:cmd < ca=3Db4 pf=3D1 nr=3D6 (2) 09:47:34.353089 i:rsp > ca=3Db4 pf=3D1 nr=3D0 ns=3D6 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1067) 09:47:34.358050 rr:cmd < ca=3Db4 pf=3D1 nr=3D7 (2) 09:47:34.358076 i:rsp > ca=3Db4 pf=3D0 nr=3D0 ns=3D7 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1062) 09:47:34.360056 i:rsp > ca=3Db4 pf=3D0 nr=3D0 ns=3D0 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (2044) 09:47:34.363052 i:rsp > ca=3Db4 pf=3D1 nr=3D0 ns=3D1 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (77) 09:47:34.857025 rr:cmd < ca=3Db4 pf=3D1 nr=3D1 (2) 09:47:34.857053 i:rsp > ca=3Db4 pf=3D1 nr=3D0 ns=3D1 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (77) 09:47:34.859023 i:cmd < ca=3Db4 pf=3D1 nr=3D2 ns=3D0 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D8 (5) 09:47:34.859051 i:rsp > ca=3Db4 pf=3D0 nr=3D1 ns=3D2 LM slsap=3D2b dlsap= =3D2b TTP=20 credits=3D0 IrCOMM (1068) Since parameters for window size is negotiable I guess MCS7780 uses 7=20 frame window, while SMSC-IIR2 uses 3 frame window. I guess this is OK?! But it is strange, how SMSC-IIR2 station replies to the I frames that=20 have Poll bit set - Instead of sending I frame with Poll(Final) bit set,=20 it sends RR frame with Poll/Final bit set?! The reason I mention this is=20 because almost every second RR frame received by the primary station=20 (MCS7780) causes 0.5 s delay. (See log below, packets from 70 - 455).=20 Reception of data on the other side of the link (same station roles)=20 acts different - MCS7780 replies to I frames with P bit set with I=20 frame, with P/F bit set. It also does not introduce 0.5 s delay when=20 receiving frames. I've also put irdadump log file on the net for you to see transfer=20 timing and similar. TXT ethereal log: https://private.cetrtapot.si/izmenjava/hinko/irdadump1.txt https://private.cetrtapot.si/izmenjava/hinko/irdadump2.txt libcap ethereal log: https://private.cetrtapot.si/izmenjava/hinko/irdadump1 https://private.cetrtapot.si/izmenjava/hinko/irdadump2 irdadump1 log includes: - MCS7780 station in SECONDARY role - SMSC-IIR2 station in PRIMARY role - connection negotiation - SNRM, UA; packets from ~ 17 ~ 38 - file transfer (100k) from SECONDARY to PRIMARY - SLOW; packets from ~=20 70 ~ 455 - file transfer (100k) from PRIMARY to SECONDARY - FAST; packets from ~=20 484 ~ 661 irdadump2 log includes: - MCS7780 station in PRIMARY role - SMSC-IIR2 station in SECONDARY role - connection negotiation - SNRM, UA; packets from ~ 17 ~ 38 - file transfer (100k) from PRIMARY to SECONDARY - SLOW; packets from ~=20 38 ~ 487 - file transfer (100k) from SECONDARY to PRIMARY - MEDIUM SLOW; packets=20 from ~ 500 ~ 781 >=20 > I don't think its happening but are there any frame drops/errors > occuring. For instance if you run irdadump on both ends do you get the > same sequence of frames, with no retransmissions occuring? I've checked ifconfig status on both machines during/after these tests=20 and there were no errors or retransmissions. thanx! best regards, hinko --=20 =C4=8CETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: hin...@ce... Http: www.cetrtapot.si |
From: <hin...@ce...> - 2006-11-13 12:29:35
|
hin...@ce... wrote: > I've also put irdadump log file on the net for you to see transfer=20 > timing and similar. > TXT ethereal log: > https://private.cetrtapot.si/izmenjava/hinko/irdadump1.txt > https://private.cetrtapot.si/izmenjava/hinko/irdadump2.txt > libcap ethereal log: > https://private.cetrtapot.si/izmenjava/hinko/irdadump1 > https://private.cetrtapot.si/izmenjava/hinko/irdadump2 >=20 Please download irdadumps mentioned above from address below instead=20 (I've forgotten that out https site requires user/pass): http://www.cetrtapot.si/irda/ Thanx, hinko --=20 =C4=8CETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: hin...@ce... Http: www.cetrtapot.si |
From: <hin...@ce...> - 2006-11-13 12:27:43
|
Alan J. McFarlane wrote: > I note that there are two instances where the inter frame gap is 0.8s. > Not in quite the same range of Minimum Turnaround Time! :-) 800 times > bigger in fact. What's the Maximum Turnaround Time value in effect? In prior tests max_turn_time was set to 500ms on both stations. Now I've=20 changed irlap.c to accept user defined max_turn_time. Ethereal dump=20 shows max_turn_time that station supports ranges from 500ms - 100ms.=20 Changing this on MCS7780 machine didn't change a bit. While modifying=20 this on SMSC-IIR2 machine it somewhat increased transmission speed from=20 few KBs to steady ~30 kBs. I've also put the irdadump packets from=20 ethereal to the site: http://www.cetrtapot.si/irda/irdadump3 http://www.cetrtapot.si/irda/irdadump3.txt What can be seen in the dump is: - MCS7780 station in SECONDARY role - SMSC-IIR2 station in PRIMARY role - modified max_turn_time makes link more responsive, still transfer=20 hiccups occur making it reach max ~30 kBs. - transfer from secondary to primary station (100k) starts at packet=20 157 - 521 - delay around RR packet is lowered from ~0.5s to 0.09 s As this looks like improved link, I'm still not happy with the transfer=20 speed in this direction. Speed in other direction can reach 350kBs and I=20 would sure like to see the same speed in this direction too! Thanx, best regards, hinko --=20 =C4=8CETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: hin...@ce... Http: www.cetrtapot.si |