From: Carlos M. <car...@gm...> - 2005-10-22 10:50:08
Attachments:
usb-autorate.log.bz2
|
Hi, So, here are some logs from an upload. There is a problem which is completely reproducible. The first time I download a file, the speed is ~220kB/s, which is around 5.5Mbit, I think, but if I stop it and then resume it (using wget all the time) the speed picks up to ~470kB/s which is the correct speed for 11Mbit. I've been trying to do it reporting the speed the device tells us, but I get such strange readings as 9Mbit and 1.6...Gbit. The others are alright, though. Oh, and your queue stop/wake works. About rates. In my mind, what we should show when we're a client is the rate at which we can send/are sending to the AP, which is what I'd call 'connection speed' or 'connected rate' and things of the sort. This is basically what the windows drivers seem to do and what I'd expect (probably because of the windows drivers, but another rant) to see when I run iwconfig. If we're in AP mode, we should show the max speed at which we permit clients to send us stuff at, since it changes for every client. Iwconfig isn't a very good interface for APs though. It's much too simple. This is where a front-end for iwpriv becomes useful. cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |
From: Denis V. <vd...@il...> - 2005-10-22 12:08:21
|
On Saturday 22 October 2005 13:49, Carlos Martin wrote: > Hi, > > So, here are some logs from an upload. > > There is a problem which is completely reproducible. The first time I > download a file, the speed is ~220kB/s, which is around 5.5Mbit, I > think, but if I stop it and then resume it (using wget all the time) > the speed picks up to ~470kB/s which is the correct speed for 11Mbit. See below, we need more reporting on requested tx rate. > I've been trying to do it reporting the speed the device tells us, but > I get such strange readings as 9Mbit and 1.6...Gbit. The others are > alright, though. Where? In the "grep 'tx: stat: ' usb-autorate.log" I see: "rate:14" - 20 dec - 2Mbit, "rate:37" - 5.5Mbit, "rate:6E" - 110 Mbit. Perfectly valid tx rates, those. Yes, it does seem to use different rates, as you said. :) But which rates were requested by driver? Please do: acxlog(L_USBRXTX, "SUBMIT TX (%d): outpipe=0x%X buf=%p txsize=%d " - "errcode=%d\n", txnum, outpipe, txbuf, - wlanpkt_len + USB_TXBUF_HDRSIZE, ucode); + "rate=%X errcode=%d\n", txnum, outpipe, txbuf, + wlanpkt_len + USB_TXBUF_HDRSIZE, rate100, ucode); Also replace L_DEBUG below with L_XFER, we need more details on auto rate code: acxlog(L_DEBUG, "tx: %sclient=%p/"MACSTR" used=%04X cur=%04X cfg=%04X " Currently it seem to operate erratically: Oct 22 11:57:29 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:37 ack_failures:00 rts_failures:00 rts_ok:00 Oct 22 11:57:29 localhost kernel: tx: stepping up to ratemask 0027 <================================= Oct 22 11:57:29 localhost kernel: 07135777 ==> acxusb_l_poll_rx Oct 22 11:57:29 localhost kernel: SUBMIT RX (5) inpipe=0xC0008380 size=4082 errcotus:00 hostdata:00000000 rate:37 ack_failures:00 rts_failures:00 rts_ok:00 Oct 22 11:57:29 localhost kernel: 07135798 ==> acxusb_l_poll_rx Oct 22 11:57:29 localhost kernel: SUBMIT RX (6) inpipe=0xC0008380 size=4082 errcode=0 Oct 22 11:57:29 localhost kernel: 07135798 <== acxusb_l_poll_rx Oct 22 11:57:29 localhost kernel: 07135798 <== acxusb_i_complete_rx Oct 22 11:57:29 localhost kernel: 07135799 ==> acxusb_i_complete_tx Oct 22 11:57:29 localhost kernel: RETURN TX (2): status=0 size=1546 Oct 22 11:57:29 localhost kernel: 07135799 <== acxusb_i_complete_tx Oct 22 11:57:29 localhost kernel: 07135801 ==> acxusb_i_complete_rx Oct 22 11:57:29 localhost kernel: RETURN RX (7) status=0 size=12 Oct 22 11:57:29 localhost kernel: packet with packetsize=12 Oct 22 11:57:29 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:37 ack_failures:00 rts_failures:00 rts_ok:00 Oct 22 11:57:29 localhost kernel: tx: falling back to ratemask 0007 <================================ ??! It must not fall back that quickly. > Oh, and your queue stop/wake works. > > About rates. In my mind, what we should show when we're a client is > the rate at which we can send/are sending to the AP, which is what I'd > call 'connection speed' or 'connected rate' and things of the sort. > This is basically what the windows drivers seem to do and what I'd > expect (probably because of the windows drivers, but another rant) to > see when I run iwconfig. > > If we're in AP mode, we should show the max speed at which we permit > clients to send us stuff at, since it changes for every client. > Iwconfig isn't a very good interface for APs though. It's much too > simple. This is where a front-end for iwpriv becomes useful. Replace acx_ioctl_get_rate with: static int acx_ioctl_get_rate( struct net_device *dev, struct iw_request_info *info, struct iw_param *vwrq, char *extra) { /* TODO: remember rate of last tx, show it. think about multiple peers... */ wlandevice_t *priv = netdev_priv(dev); unsigned long flags; u16 rate; acx_lock(priv, flags); rate = priv->rate_oper; if(priv->ap_client) rate = priv->ap_client->rate_cur; vwrq->value = acx111_rate_tbl[highest_bit(rate)]; vwrq->fixed = !priv->rate_auto; vwrq->disabled = 0; acx_unlock(priv, flags); return OK; } -- vda |
From: Denis V. <vd...@il...> - 2005-10-22 12:30:40
|
On Saturday 22 October 2005 13:49, Carlos Martin wrote: > Hi, > > So, here are some logs from an upload. Another thing which may be useful to reduce/eliminate "missing log" syndrome: Oct 22 11:57:23 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:37 ack_failures:00 rts_failure2 Oct 22 11:57:23 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:14 ack_failures:00 rts_failures:00 rts_ok:00 is to bump up CONFIG_LOG_BUF_SHIFT=15 in kernel .config to something bigger. It's under "Kernel hacking" in menuconfig: (15) Kernel log buffer size (16 => 64KB, 17 => 128KB) -- vda |
From: Carlos M. <car...@gm...> - 2005-10-22 17:07:26
Attachments:
usb-autorate2.log.bz2
|
Here you go. Logs with your changes. I would have sent it earlier, but "my Internet broke". cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |
From: Denis V. <vd...@il...> - 2005-10-23 10:29:09
Attachments:
klog.tar.bz2
|
On Saturday 22 October 2005 20:07, Carlos Martin wrote: > Here you go. Logs with your changes. I would have sent it earlier, but > "my Internet broke". Thanks! Looks like your logging system (klogd+syslogd or whatever) is losing large pieces of kernel log. But anyway: # grep 'tx:' usb-autorate2.log | grep -v 'wake ' | grep -v 'stat: mac_cnt_rcvd:' | $PAGER Oct 22 15:21:07 localhost kernel: tx: falling back to ratemask 0003 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=1/10 ^^^^^^^^^ With ratemask cur=3 (000011) PCI driver uses 2Mbit rate. USB apparently used 5.5Mbit! You must be right about USB doing it's own rate management. Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=2/10 Here we lose a large piece of log (stepup counter "jumps" from 2/10 to 8/10)... Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0003 cfg=0027 __=0/3 ^^=8/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0003 cfg=0027 __=0/3 ^^=9/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0003 cfg=0027 __=0/3 ^^=10/10 Oct 22 15:21:07 localhost kernel: tx: stepping up to ratemask 0007 Basically this means that this piece of code seems to be not needed: if (priv->rate_auto && stat->hostdata < VEC_SIZE(priv->sta_list)) { client_t *clt = &priv->sta_list[stat->hostdata]; acx_l_handle_txrate_auto(priv, clt, stat->rate, 0 /*rate111*/, stat->mac_status /*error*/, ACX_URB_CNT - priv->tx_free); } Consider testing throughput with and without it (with logging off of course). Loss of logging produces a number of puzzling fragments: Oct 22 15:21:07 localhost kernel: tx: falling back to ratemask 0003 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:RN RX (2) status=0 size=430 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=1/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=2/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=3/10 [LOST] Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0003 cfg=0027 __=0/3 ^^=7/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0003 cfg=0027 __=0/3 ^^=8/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0003 cfg=0027 __=0/3 ^^=9/10 [LOST] Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0007 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0007 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0007 cfg=0027 __=0/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0007 cfg=0027 __=1/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0007 cfg=0027 __=2/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0002 cur=0007 cfg=0027 __=3/3 ^^=0/10 Oct 22 15:21:07 localhost kernel: tx: falling back to ratemask 0003 stepup event was lost in between of two fallback ones! :( I am using a socklog tool from http://smarden.org/socklog/ Can be run standalone but I use it in combination with daemontools from http://cr.yp.to/daemontools.html Attached is the tarball of directory with necessary scripts. If you will fail to convince your klogd to work properly, try socklog instead. -- vda |
From: Carlos M. <car...@gm...> - 2005-10-23 11:09:04
|
On 23/10/05, Denis Vlasenko <vd...@il...> wrote: > On Saturday 22 October 2005 20:07, Carlos Martin wrote: > > Here you go. Logs with your changes. I would have sent it earlier, but > > "my Internet broke". > > Thanks! > > Looks like your logging system (klogd+syslogd or whatever) is losing > large pieces of kernel log. But anyway: > > # grep 'tx:' usb-autorate2.log | grep -v 'wake ' | grep -v 'stat: mac_cnt= _rcvd:' | $PAGER > > Oct 22 15:21:07 localhost kernel: tx: falling back to ratemask 0003 > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=3Dd0fe04b4/00:80:5A:29= :08:4B used=3D0004 cur=3D0003 cfg=3D0027 __=3D0/3 ^^=3D0/10 > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=3Dd0fe04b4/00:80:5A:29= :08:4B used=3D0004 cur=3D0003 cfg=3D0027 __=3D0/3 ^^=3D0/10 > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=3Dd0fe04b4/00:80:5A:29= :08:4B used=3D0004 cur=3D0003 cfg=3D0027 __=3D0/3 ^^=3D0/10 > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=3Dd0fe04b4/00:80:5A:29= :08:4B used=3D0004 cur=3D0003 cfg=3D0027 __=3D0/3 ^^=3D0/10 > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=3Dd0fe04b4/00:80:5A:29= :08:4B used=3D0004 cur=3D0003 cfg=3D0027 __=3D0/3 ^^=3D0/10 > Oct 22 15:21:07 localhost kernel: tx: client=3Dd0fe04b4/00:80:5A:29:08:4B= used=3D0004 cur=3D0003 cfg=3D0027 __=3D0/3 ^^=3D1/10 > ^= ^^^^^^^^ > With ratemask cur=3D3 (000011) PCI driver uses 2Mbit rate. USB ap= parently used 5.5Mbit! > You must be right about USB doing it's own rate management. Yeah, but it doesn't always go on its own. Attached are three logs. the -autorate is the 1023 snapshot as-is. -noautorate is 1023 without the autorate call in the TXSTAT codepath. -fixedrate is without auto after the rate in iwconfig. Without the call, driver always tells the device to try 1M, and because we don't adjust it, it stays at 1Mbit. With the autorate code, the first download goes at 5.5Mbit and the second at 11Mbit (wget, stop it and download again). With fixed rate you get 11Mbit all the way. The speed reaches <600kB/s at 11Mbit, ~220kB/s with 5.5Mbit and ~90kB/s at 1Mbit cur=3D0007 cfg=3D0027 __=3D1/3 ^^=3D0/10 > Oct 22 15:21:07 localhost kernel: tx: client=3Dd0fe04b4/00:80:5A:29:08:4B= used=3D0002 cur=3D0007 cfg=3D0027 __=3D2/3 ^^=3D0/10 > Oct 22 15:21:07 localhost kernel: tx: client=3Dd0fe04b4/00:80:5A:29:08:4B= used=3D0002 cur=3D0007 cfg=3D0027 __=3D3/3 ^^=3D0/10 > Oct 22 15:21:07 localhost kernel: tx: falling back to ratemask 0003 > > stepup event was lost in between of two fallback ones! :( I'm not sure why it's losing info. I'll try with the socklog and see if it doesn't do it. cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |
From: Denis V. <vd...@il...> - 2005-10-23 11:55:06
|
On Sunday 23 October 2005 14:08, Carlos Martin wrote: > On 23/10/05, Denis Vlasenko <vd...@il...> wrote: > > On Saturday 22 October 2005 20:07, Carlos Martin wrote: > > > Here you go. Logs with your changes. I would have sent it earlier, but > > > "my Internet broke". > > > > Thanks! > > > > Looks like your logging system (klogd+syslogd or whatever) is losing > > large pieces of kernel log. But anyway: > > > > # grep 'tx:' usb-autorate2.log | grep -v 'wake ' | grep -v 'stat: mac_cnt_rcvd:' | $PAGER > > > > Oct 22 15:21:07 localhost kernel: tx: falling back to ratemask 0003 > > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 > > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 > > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 > > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 > > Oct 22 15:21:07 localhost kernel: tx: [IGN] client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=0/10 > > Oct 22 15:21:07 localhost kernel: tx: client=d0fe04b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=1/10 > > ^^^^^^^^^ > > With ratemask cur=3 (000011) PCI driver uses 2Mbit rate. USB apparently used 5.5Mbit! > > You must be right about USB doing it's own rate management. > > Yeah, but it doesn't always go on its own. Attached are three logs. > the -autorate is the 1023 snapshot as-is. -noautorate is 1023 without > the autorate call in the TXSTAT codepath. -fixedrate is without auto > after the rate in iwconfig. hmm... "creating /proc entry driver/acx_wlan%%d" is my fault, fixed... > Without the call, driver always tells the device to try 1M, and > because we don't adjust it, it stays at 1Mbit. /me is looking at output of # (grep 'rate[:=]' | grep -v 'rx:' | $PAGER) <dmesg-noautorate.log Yes. rate is uniformly 10 (= 1Mbit): Oct 23 12:49:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:10 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:49:07 localhost kernel: SUBMIT TX (6): outpipe=0xC0008300 buf=cfb837a4 txsize=1546 rate=A errcode=0 Oct 23 12:49:07 localhost kernel: SUBMIT TX (7): outpipe=0xC0008300 buf=cfb840e8 txsize=1546 rate=A errcode=0 Oct 23 12:49:07 localhost kernel: SUBMIT TX (0): outpipe=0xC0008300 buf=cfb8000c txsize=1546 rate=A errcode=0 Oct 23 12:49:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:10 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:49:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:10 ack_failures:00 rts_failures:00 rts_ok:00 (rate=<decimal> is fixed for tomorrow's tarball) > With the autorate code, > the first download goes at 5.5Mbit and the second at 11Mbit (wget, > stop it and download again). # (grep -E '(rate[:=])|(ratemask)' | grep -v 'rx:' | $PAGER) <dmesg-autorate.log Something strange happened here: ... Oct 23 12:46:07 localhost kernel: tx: stepping up to ratemask 0007 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:20 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: SUBMIT TX (0): outpipe=0xC0008300 buf=d299800c txsize=1546 rate=37 errcode=0 Oct 23 12:46:07 localhost kernel: SUBMIT TX (1): outpipe=0xC0008300 buf=d2998950 txsize=1546 rate=37 errcode=0 Oct 23 12:46:07 localhost kernel: SUBMIT TX (2): outpipe=0xC0008300 buf=d2999294 txsize=1546 rate=37 errcode=0 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:20 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:20 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:20 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: SUBMIT TX (3): outpipe=0xC0008300 buf=d2999bd8 txsize=1546 rate=37 errcode=0 Oct 23 12:46:07 localhost kernel: SUBMIT TX (2): outpipe=0xC0008300 buf=d2999294 txsize=1546 rate=14 errcode=0 Oct 23 12:46:07 localhost kernel: SUBMIT TX (3): outpipe=0xC0008300 buf=d2999bd8 txsize=1546 rate=14 errcode=0 Oct 23 12:46:07 localhost kernel: SUBMIT TX (4): outpipe=0xC0008300 buf=d299a51c txsize=1546 rate=14 errcode=0 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:20 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:55 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:55 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:55 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: SUBMIT TX (4): outpipe=0xC0008300 buf=d299a51c txsize=1546 rate=6E errcode=0 oops! Suddenly we started to submit 110 (0x6E) rate byte??! Oct 23 12:46:07 localhost kernel: SUBMIT TX (5): outpipe=0xC0008300 buf=d299ae60 txsize=1546 rate=6E errcode=0 Oct 23 12:46:07 localhost kernel: SUBMIT TX (6): outpipe=0xC0008300 buf=d299b7a4 txsize=1546 rate=6E errcode=0 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:55 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:55 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:110 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:110 ack_failures:00 rts_failures:00 rts_ok:00 This is the log part between last "normal" SUBMIT TX and first "mysterious" one: Oct 23 12:46:07 localhost kernel: SUBMIT TX (4): outpipe=0xC0008300 buf=d299a51c txsize=1546 rate=14 errcode=0 Oct 23 12:46:07 localhost kernel: 00632103 <== acxusb_l_tx_data Oct 23 12:46:07 localhost kernel: 00632103 <== acx_i_start_xmit: 00000000 Oct 23 12:46:07 localhost kernel: 00632108 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (0) status=0 size=12 Oct 23 12:46:07 localhost kernel: packet with packetsize=12 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:20 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: client=d17644b4/00:80:5A:29:08:4B used=0002 cur=0003 cfg=0027 __=0/3 ^^=5/10 Oct 23 12:46:07 localhost kernel: 00632108 ==> acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: SUBMIT RX (0) inpipe=0xC0008380 size=4082 errcode=0 Oct 23 12:46:07 localhost kernel: 00632108 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632108 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632110 ==> acxusb_i_complete_tx Oct 23 12:46:07 localhost kernel: RETURN TX (7): status=0 size=1546 Oct 23 12:46:07 localhost kernel: 00632110 <== acxusb_i_complete_tx Oct 23 12:46:07 localhost kernel: 00632110 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (1) status=0 size=90 Oct 23 12:46:07 localhost kernel: packet with packetsize=90 Oct 23 12:46:07 localhost kernel: rx: DATA/DataOnly time:137375433 len:78 signal:69 SNR:0 macstat:83 phystat:04 phyrate:110 status:4 Oct 23 12:46:07 localhost kernel: 00632110 ==> acx_l_rx_ieee802_11_frame Oct 23 12:46:07 localhost kernel: 00632110 ==> acx_l_process_data_frame_client Oct 23 12:46:07 localhost kernel: 00632110 ==> acx_l_rx Oct 23 12:46:07 localhost kernel: 00632110 ==> acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: rx: frame info: llc=AAAA03 snap.oui=000000 snap.type=0800 Oct 23 12:46:07 localhost kernel: 00632110 <== acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: 00632110 <== acx_l_rx Oct 23 12:46:07 localhost kernel: 00632110 <== acx_l_process_data_frame_client: 00000000 Oct 23 12:46:07 localhost kernel: 00632110 <== acx_l_rx_ie_rx Oct 23 12:46:07 localhost kernel: SUBMIT RX (5) inpipe=0xC0008380 size=4082 errcode=0 Oct 23 12:46:07 localhost kernel: 00632216 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632216 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632219 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (6) status=0 size=12 Oct 23 12:46:07 localhost kernel: packet with packetsize=12 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:55 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: client=d17644b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=1/10 Oct 23 12:46:07 localhost kernel: 00632219 ==> acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: SUBMIT RX (6) inpipe=0xC0008380 size=4082 errcode=0 Oct 23 12:46:07 localhost kernel: 00632219 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632219 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632222 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (7) status=0 size=90 Oct 23 12:46:07 localhost kernel: packet with packetsize=90 Oct 23 12:46:07 localhost kernel: rx: DATA/DataOnly time:137486251 len:78 signal:69 SNR:0 macstat:83 phystat:04 phyrate:110 status:4 Oct 23 12:46:07 localhost kernel: 00632222 ==> acx_l_rx_ieee802_11_frame Oct 23 12:46:07 localhost kernel: 00632222 ==> acx_l_process_data_frame_client Oct 23 12:46:07 localhost kernel: 00632222 ==> acx_l_rx Oct 23 12:46:07 localhost kernel: 00632222 ==> acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: rx: frame info: llc=AAAA03 snap.oui=000000 snap.type=0800 Oct 23 12:46:07 localhost kernel: 00632222 <== acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: 00632222 <== acx_l_rx Oct 23 12:46:07 localhost kernel: 00632222 <== acx_l_process_data_frame_client: 00000000 Oct 23 12:46:07 localhost kernel: 00632222 <== acx_l_rx_ieee802_11_frame: 00000000 Oct 23 12:46:07 localhost kernel: 00632222 ==> acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: SUBMIT RX (7) inpipe=0xC0008380 size=4082 errcode=0 Oct 23 12:46:07 localhost kernel: 00632222 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632222 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632223 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (0) status=0 size=90 Oct 23 12:46:07 localhost kernel: packet with packetsize=90 Oct 23 12:46:07 localhost kernel: rx: DATA/DataOnly time:137486831 len:78 signal:74 SNR:0 macstat:83 phystat:04 phyrate:110 status:4 Oct 23 12:46:07 localhost kernel: 00632223 ==> acx_l_rx_ieee802_11_frame Oct 23 12:46:07 localhost kernel: 00632223 ==> acx_l_process_data_frame_client Oct 23 12:46:07 localhost kernel: 00632223 ==> acx_l_rx Oct 23 12:46:07 localhost kernel: 00632223 ==> acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: rx: frame info: llc=AAAA03 snap.oui=000000 snap.type=0800 Oct 23 12:46:07 localhost kernel: 00632223 <== acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: 00632223 <== acx_l_rx Oct 23 12:46:07 localhost kernel: 00632223 <== acx_l_process_data_frame_client: 00000000 Oct 23 12:46:07 localhost kernel: 00632223 <== acx_l_rx_ieee802_11_frame: 00000000 Oct 23 12:46:07 localhost kernel: 00632223 ==> acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: SUBMIT RX (0) inpipe=0xC0008380 size=4082 errcode=0 Oct 23 12:46:07 localhost kernel: 00632223 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632223 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632224 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (1) status=0 size=12 Oct 23 12:46:07 localhost kernel: packet with packetsize=12 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:55 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: client=d17644b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=2/10 Oct 23 12:46:07 localhost kernel: 00632224 ==> acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: SUBMIT RX (1) inpipe=0xC0008380 size=4082 errcode=0 Oct 23 12:46:07 localhost kernel: 00632224 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632224 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632226 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (2) status=0 size=12 Oct 23 12:46:07 localhost kernel: packet with packetsize=12 Oct 23 12:46:07 localhost kernel: tx: stat: mac_cnt_rcvd:8000 queue_index:01 mac_status:00 hostdata:00000000 rate:55 ack_failures:00 rts_failures:00 rts_ok:00 Oct 23 12:46:07 localhost kernel: tx: client=d17644b4/00:80:5A:29:08:4B used=0004 cur=0003 cfg=0027 __=0/3 ^^=3/10 Oct 23 12:46:07 localhost kernel: 00632226 ==> acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: SUBMIT RX (2) inpipe=0xC0008380 size=4082 errcode=0 Oct 23 12:46:07 localhost kernel: 00632226 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632226 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632227 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (3) status=0 size=90 Oct 23 12:46:07 localhost kernel: packet with packetsize=90 Oct 23 12:46:07 localhost kernel: rx: DATA/DataOnly time:137493266 len:78 signal:71 SNR:0 macstat:83 phystat:04 phyrate:110 status:4 Oct 23 12:46:07 localhost kernel: 00632227 ==> acx_l_rx_ieee802_11_frame Oct 23 12:46:07 localhost kernel: 00632227 ==> acx_l_process_data_frame_client Oct 23 12:46:07 localhost kernel: 00632227 ==> acx_l_rx Oct 23 12:46:07 localhost kernel: 00632227 ==> acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: rx: frame info: llc=AAAA03 snap.oui=000000 snap.type=0800 Oct 23 12:46:07 localhost kernel: 00632227 <== acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: 00632227 <== acx_l_rx Oct 23 12:46:07 localhost kernel: 00632227 <== acx_l_process_data_frame_client: 00000000 Oct 23 12:46:07 localhost kernel: 00632227 <== acx_l_rx_ieee802_11_frame: 00000000 Oct 23 12:46:07 localhost kernel: 00632227 ==> acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: SUBMIT RX (3) inpipe=0xC0008380 size=4082 errcode=0 Oct 23 12:46:07 localhost kernel: 00632227 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632227 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632228 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (4) status=0 size=90 Oct 23 12:46:07 localhost kernel: packet with packetsize=90 Oct 23 12:46:07 localhost kernel: rx: DATA/DataOnly time:137493806 len:78 signal:69 SNR:0 macstat:83 phystat:04 phyrat [LOST!] rrcode=0 Oct 23 12:46:07 localhost kernel: 00632580 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632580 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632580 ==> acxusb_i_complete_tx Oct 23 12:46:07 localhost kernel: RETURN TX (0): status=0 size=1546 Oct 23 12:46:07 localhost kernel: 00632580 <== acxusb_i_complete_tx Oct 23 12:46:07 localhost kernel: 00632581 ==> acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: RETURN RX (5) status=0 size=90 Oct 23 12:46:07 localhost kernel: packet with packetsize=90 Oct 23 12:46:07 localhost kernel: rx: DATA/DataOnly time:137847150 len:78 signal:71 SNR:0 macstat:83 phystat:04 phyrate:110 status:4 Oct 23 12:46:07 localhost kernel: 00632581 ==> acx_l_rx_ieee802_11_frame Oct 23 12:46:07 localhost kernel: 00632581 ==> acx_l_process_data_frame_client Oct 23 12:46:07 localhost kernel: 00632581 ==> acx_l_rx Oct 23 12:46:07 localhost kernel: 00632581 ==> acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: rx: frame info: llc=AAAA03 snap.oui=000000 snap.type=0800 Oct 23 12:46:07 localhost kernel: 00632581 <== acx_rxbuf_to_ether Oct 23 12:46:07 localhost kernel: 00632581 <== acx_l_rx Oct 23 12:46:07 localhost kernel: 00632581 <== acx_l_process_data_frame_client: 00000000 Oct 23 12:46:07 localhost kernel: 00632581 <== acx_l_rx_ieee802_11_frame: 00000000 Oct 23 12:46:07 localhost kernel: 00632581 ==> acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: SUBMIT RX (5) inpipe=0xC0008380 size=4082 errcode=0 Oct 23 12:46:07 localhost kernel: 00632581 <== acxusb_l_poll_rx Oct 23 12:46:07 localhost kernel: 00632581 <== acxusb_i_complete_rx Oct 23 12:46:07 localhost kernel: 00632581 ==> acxusb_i_complete_tx Oct 23 12:46:07 localhost kernel: RETURN TX (1): status=0 size=1546 Oct 23 12:46:07 localhost kernel: 00632581 <== acxusb_i_complete_tx Oct 23 12:46:07 localhost kernel: 00632582 ==> acx_i_start_xmit Oct 23 12:46:07 localhost kernel: 00632582 ==> acxusb_l_alloc_tx Oct 23 12:46:07 localhost kernel: allocated tx 4 Oct 23 12:46:07 localhost kernel: 00632582 <== acxusb_l_alloc_tx Oct 23 12:46:07 localhost kernel: 00632582 ==> acx_ether_to_txbuf Oct 23 12:46:07 localhost kernel: 00632582 <== acx_ether_to_txbuf: 000005FC Oct 23 12:46:07 localhost kernel: 00632582 ==> acxusb_l_tx_data Oct 23 12:46:07 localhost kernel: SUBMIT TX (4): outpipe=0xC0008300 buf=d299a51c txsize=1546 rate=6E errcode=0 I don't see where clt->rate100 was suddenly changed to 110. It must have happened in that [LOST!] part. This is how rate is set: rate100 = clt ? clt->rate_100 : priv->rate_bcast100; ... txbuf->rate = rate100; > > stepup event was lost in between of two fallback ones! :( > > I'm not sure why it's losing info. I'll try with the socklog and see > if it doesn't do it. I guess it's kernel msg buffer overflow (klog may be too slow at reading the ring buffer) -- vda |
From: Carlos M. <car...@gm...> - 2005-10-23 12:51:47
|
On 23/10/05, Denis Vlasenko <vd...@il...> wrote: > if it doesn't do it. > > I guess it's kernel msg buffer overflow (klog may be too slow at reading > the ring buffer) It does sound like it. The loss happens when the rate goes up as well, at which point the messages would come in at a much higher speed. On a related note, my router is now using the ACX100 USB device. From tomorrow onwards, my Internet access will most likely be only through this device, so I won't be able to test it as often as I could before. If I'm lucky, I'll be able to use another card, but I wouldn't count on it. cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |
From: Carlos M. <car...@gm...> - 2005-10-23 15:58:17
|
On 23/10/05, Denis Vlasenko <vd...@il...> wrote: > On Sunday 23 October 2005 15:51, Carlos Martin wrote: > > On 23/10/05, Denis Vlasenko <vd...@il...> wrote: > > > if it doesn't do it. > > > > > > I guess it's kernel msg buffer overflow (klog may be too slow at read= ing > > > the ring buffer) > > > > It does sound like it. The loss happens when the rate goes up as well, > > at which point the messages would come in at a much higher speed. > > Try to bump up CONFIG_LOG_BUF_SHIFT=3Dnn in kernel .config, > and also you may turn off L_FUNC bit in acx debug mask > (will make log much shorter). The shift is already at 17. I'll take the L_FUNC bit out. > > > On a related note, my router is now using the ACX100 USB device. From > > tomorrow onwards, my Internet access will most likely be only through > > this device, so I won't be able to test it as often as I could before. > > If I'm lucky, I'll be able to use another card, but I wouldn't count > > on it. > > Whew, an acx usb in production environment :) It's working alright for now. > > Please find attached tarball. Since after looking at your logs > I am a bit puzzled I'd like to have requested rate to be recorded > into hostdata so that I san see it in struct txstatus. Now I have to find a time to do an scheduled downtime ;) which isn't going to be easy given my brother's downloading habits. I'll get some logs to you... eventually cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |
From: Carlos M. <car...@gm...> - 2005-10-25 20:03:57
|
Well, the USB device is dead. I wasn't here on Monday because I was on a school trip and when I got home someone had managed to push the plug so hard into the device that it broke. The socket was literally ripped from Where It Should Be(tm). Took some pics of the inside though. In case anyone is interested, the photos are at http://www.cmartin.tk/acx/ as one would expect, although the camera's focus wasn't cooperating much. My dad will try to get another one tomorrow from the same people we got this one, but I'll be some time without access to the device. Hell, my Internet connection is an improvised hack I'm surprised actually works (even more than the original untested spur-of-the-moment solution). You know what they say about showing people proof-of-concept solutions... Wish me luck. cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |
From: Andreas M. <an...@us...> - 2005-10-25 20:26:38
|
Hi, On Tue, Oct 25, 2005 at 10:03:48PM +0200, Carlos Martin wrote: > Well, the USB device is dead. I wasn't here on Monday because I was on > a school trip and when I got home someone had managed to push the plug > so hard into the device that it broke. The socket was literally ripped > from Where It Should Be(tm). Took some pics of the inside though. In > case anyone is interested, the photos are at > http://www.cmartin.tk/acx/ as one would expect, although the camera's > focus wasn't cooperating much. But OTOH it doesn't look TOO bad, should be relatively easily fixable... BTW, let me guess... this incredible temporary internet hack involves lots of OSS solutions? Now let me guess that this would be absolutely impossible using dumb Windows functionality? ;) (ok, maybe I'm totally wrong, but who knows... ;) Andreas -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta |
From: Carlos M. <car...@gm...> - 2005-10-25 21:05:04
|
On 25/10/05, Andreas Mohr <an...@us...> wrote: > But OTOH it doesn't look TOO bad, should be relatively easily fixable... With some precision soldering yes. The connections from the socket to the PCB have all been ripped apart, and each has a different length. There's another pic on now. The thing that's slightly off to one side is the socket. The soldering skill that would be needed is clearly way above me. The only soldering I've done was two or three years ago (back in compulsory education) with much bigger chunks of stuff. Each of the connectors is slightly less than 1mm wide. One could try to hold it in place, but I don't know. > > BTW, let me guess... this incredible temporary internet hack involves lot= s of > OSS solutions? My original almost-improvised solution was to use a Pentium III as a router using Linux. This was using the USB device quite happily. The reason it was spur-of-the-moment is because it was the fastest way to get my brother to shut up about the Internet connection. I was getting the system ready so that on Monday all we had to do was turn it on and All Would Be Good. I still have to load the iptables rules by hand, activate IP forwarding and load the driver. I was going to test the start-up scripts, but my brother was already heavily relying on this solution (thus my comment on showing people proof-of-concept). > Now let me guess that this would be absolutely impossible using dumb Wind= ows > functionality? ;) > > (ok, maybe I'm totally wrong, but who knows... ;) The reason I'm surprised it (the improvised hack) works is precisely because I'm using Windows. The network will only lease an IP (and permit access) to the MAC address of the USB device, so I changed the MAC on my desktop and I use that to connect. The AP is then connected through Ethernet and everything else through that. I would have done it using Linux, but I wasn't sure how to change the MAC address. Another reason is that I was just back from spending half a day walking and couldn't be bothered getting up again and changing the antennas on the cards, and the whole setup was almost as I wanted it with Windows anyway, because I was giving the router access to the Internet (this was before it became the router) using my desktop. Note that my router uses Linux From Scratch, so there is little in the form of automation. I've modified the network scripts so they work as I need them to, but they're largely untested. Some weren't working yesterday, but they should now. We'll see what tomorrow brings. The most surprising thing is that I told Windows I wanted to share it through a network. Said network (ethernet card) isn't actually active. Everything goes through another card and another set of IP addresses. This is what boggles my mind. Windows asks me (demands of me) which network I'd like to share it with, changes its IP address without any notice, sets up a DHCP server and then doesn't even check where the packets are coming from! cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |
From: Carlos M. <car...@gm...> - 2005-10-25 21:15:45
|
On 25/10/05, Carlos Martin <car...@gm...> wrote: > (back in compulsory education) with much bigger chunks of stuff. Each > of the connectors is slightly less than 1mm wide. One could try to > hold it in place, but I don't know. Actually, I've just tested, and if I hold it with my hand, I can get it to work It even picks up more signal than my PCI card. There shall be experimets with cellotape tomorrow. cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |
From: Carlos M. <car...@gm...> - 2005-10-30 09:34:28
Attachments:
dmesg.log.bz2
|
Right, here we go. After having the device soldered by the ISP (talk about tech support ;) I've managed to do the test. I did it yesterday, but it appears Linux reads the routing table the wrong way round (oldest rules first) to the whole thing came out the wrong ifnterface. The logging is done with 0xfcdf. It seems it works this time round, but it does take some time to get up to speed. The upload speed was ~360kB/s which is a bit slow, though. cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |
From: Denis V. <vd...@il...> - 2005-10-30 17:50:36
|
On Sunday 30 October 2005 10:34, Carlos Martin wrote: > Right, here we go. After having the device soldered by the ISP (talk > about tech support ;) I've managed to do the test. I did it yesterday, > but it appears Linux reads the routing table the wrong way round > (oldest rules first) to the whole thing came out the wrong ifnterface. > > The logging is done with 0xfcdf. It seems it works this time round, > but it does take some time to get up to speed. The upload speed was > ~360kB/s which is a bit slow, though. Looks like our "ignore count" machinery is not working as intended. You may do quick experiments with adding a small constant NN which will delay fallback for NN packets: if (priv->rate_auto && client_no < VEC_SIZE(priv->sta_list)) { client_t *clt = &priv->sta_list[client_no]; acx_l_handle_txrate_auto(priv, clt, stat->rate, 0 /*rate111*/, stat->mac_status /*error*/, HERE =====> ACX_URB_CNT - priv->tx_free + NN); } I will work on better fix. -- vda |
From: Andreas M. <an...@us...> - 2005-10-30 11:25:32
|
Hi, On Sun, Oct 30, 2005 at 10:34:13AM +0200, Carlos Martin wrote: > Right, here we go. After having the device soldered by the ISP (talk > about tech support ;) I've managed to do the test. I did it yesterday, > but it appears Linux reads the routing table the wrong way round > (oldest rules first) to the whole thing came out the wrong ifnterface. Whoa, what ISP was that?? Methinks I really need to move over there... ;-) Andreas |
From: Carlos M. <car...@gm...> - 2005-10-30 13:07:41
|
On 30/10/05, Andreas Mohr <an...@us...> wrote: > Hi, > > On Sun, Oct 30, 2005 at 10:34:13AM +0200, Carlos Martin wrote: > > Right, here we go. After having the device soldered by the ISP (talk > > about tech support ;) I've managed to do the test. I did it yesterday, > > but it appears Linux reads the routing table the wrong way round > > (oldest rules first) to the whole thing came out the wrong ifnterface. > Whoa, what ISP was that?? It's Macovall, and it's only a sort-of ISP. It's founded (in part) by the town halls of the area and it's a "community project". The founding for the ISP part was (is?) given by Europe (which usually means you Germans) because this area doesn't have DSL or cable possibilities. The copper was laid down back when the government owned _the_ telco company (Telef=F3nica) and they managed to give us ISDN before the market opened and the telco was privatised. Of course, this means that Telefonica no longer _has_ to provide us with anything (although they kept ownership of the cables) which in essence means many small villages won't get connected, although this is really a different rant. Basically the ISP is very local (around 60 villages with population counts of under 1000 each) and the first month they gave us free (and the second one because the network fell all the time) and because we stayed with them, we got to keep the wireless device they gave you for the trial period. Can you guess what device they gave us? Of course, when I asked, they said it was no problem and that they used those same cards with their Linux setups. Yeah, right... > Methinks I really need to move over there... ;-) You're welcome to. It would really raise the computer literacy values way up. :-) cmn -- Carlos Mart=EDn Nieto http://www.cmartin.tk "=BFHan entendido?" "S=ED, nosotros vemos La 2" -- Emilio, "Aqu=ED no hay quien viva" |