Hi!
Ping time is around 50msec, and that seems pretty much okay, but
10KB/sec seems like way too low.
I am limited to 10KB/sec both on linux-to-linux bnetp transfers and it
limits my transfer rates using edge and n6230, too :-(.
Ping times during transfer:
64 bytes from 10.1.0.3: icmp_seq=149 ttl=64 time=62.8 ms
64 bytes from 10.1.0.3: icmp_seq=150 ttl=64 time=64.2 ms
64 bytes from 10.1.0.3: icmp_seq=151 ttl=64 time=85.9 ms
64 bytes from 10.1.0.3: icmp_seq=152 ttl=64 time=80.3 ms
64 bytes from 10.1.0.3: icmp_seq=153 ttl=64 time=132.1 ms
64 bytes from 10.1.0.3: icmp_seq=154 ttl=64 time=64.8 ms
64 bytes from 10.1.0.3: icmp_seq=155 ttl=64 time=128.3 ms
64 bytes from 10.1.0.3: icmp_seq=156 ttl=64 time=116.3 ms
64 bytes from 10.1.0.3: icmp_seq=157 ttl=64 time=120.5 ms
64 bytes from 10.1.0.3: icmp_seq=158 ttl=64 time=240.2 ms
64 bytes from 10.1.0.3: icmp_seq=159 ttl=64 time=111.2 ms
64 bytes from 10.1.0.3: icmp_seq=160 ttl=64 time=382.1 ms
64 bytes from 10.1.0.3: icmp_seq=161 ttl=64 time=912.6 ms
64 bytes from 10.1.0.3: icmp_seq=162 ttl=64 time=1612.1 ms
64 bytes from 10.1.0.3: icmp_seq=163 ttl=64 time=4373.6 ms
64 bytes from 10.1.0.3: icmp_seq=164 ttl=64 time=5128.8 ms
64 bytes from 10.1.0.3: icmp_seq=165 ttl=64 time=7191.1 ms
64 bytes from 10.1.0.3: icmp_seq=166 ttl=64 time=9473.1 ms
64 bytes from 10.1.0.3: icmp_seq=167 ttl=64 time=8469.0 ms
64 bytes from 10.1.0.3: icmp_seq=168 ttl=64 time=10040.7 ms
64 bytes from 10.1.0.3: icmp_seq=169 ttl=64 time=9036.7 ms
64 bytes from 10.1.0.3: icmp_seq=170 ttl=64 time=10681.1 ms
64 bytes from 10.1.0.3: icmp_seq=171 ttl=64 time=9677.1 ms
64 bytes from 10.1.0.3: icmp_seq=172 ttl=64 time=8673.0 ms
64 bytes from 10.1.0.3: icmp_seq=173 ttl=64 time=10685.0 ms
64 bytes from 10.1.0.3: icmp_seq=174 ttl=64 time=9681.0 ms
64 bytes from 10.1.0.3: icmp_seq=175 ttl=64 time=8677.0 ms
64 bytes from 10.1.0.3: icmp_seq=176 ttl=64 time=11997.2 ms
64 bytes from 10.1.0.3: icmp_seq=177 ttl=64 time=10993.4 ms
64 bytes from 10.1.0.3: icmp_seq=178 ttl=64 time=9989.3 ms
64 bytes from 10.1.0.3: icmp_seq=179 ttl=64 time=13797.3 ms
64 bytes from 10.1.0.3: icmp_seq=180 ttl=64 time=12793.3 ms
64 bytes from 10.1.0.3: icmp_seq=181 ttl=64 time=11789.1 ms
64 bytes from 10.1.0.3: icmp_seq=182 ttl=64 time=10784.9 ms
64 bytes from 10.1.0.3: icmp_seq=183 ttl=64 time=9781.1 ms
Netdev watchdog complains a lot:
Oct 22 18:53:57 amd pand[2439]: Bluetooth PAN daemon version 2.19
Oct 22 18:53:57 amd pand[2439]: Connecting to <won't tell you>
Oct 22 18:53:58 amd pand[2439]: bnep0 connected
Oct 22 18:54:37 amd kernel: usb 3-1: USB disconnect, address 2
Oct 22 18:55:33 amd kernel: NETDEV WATCHDOG: bnep0: transmit timed out
Oct 22 18:55:59 amd last message repeated 2 times
Oct 22 18:56:51 amd last message repeated 5 times
Oct 22 18:57:55 amd last message repeated 3 times
Oct 22 18:59:03 amd last message repeated 7 times
I use this to set up billionton:
setserial /dev/ttyBT baud_base 921600
hciattach -s 921600 /dev/ttyBT bcsp
root@amd:~# tcpspray -n 1 -b 1000000 10.1.0.3
Transmitted 1000000 bytes in 163.256781 seconds (5.982 kbytes/s)
(okay, this was little slower, I was far from other side). Most tests
look like this:
root@amd:~# tcpspray -n 1 -b 1000000 10.1.0.3
Transmitted 1000000 bytes in 103.183640 seconds (9.464 kbytes/s)
Pavel
--
Thanks, Sharp!
On Saturday 22 October 2005 13:31, Pavel Machek wrote:
> Hi!
>
> Ping time is around 50msec, and that seems pretty much okay, but
> 10KB/sec seems like way too low.
>
> I am limited to 10KB/sec both on linux-to-linux bnetp transfers and it
> limits my transfer rates using edge and n6230, too :-(.
>
> Ping times during transfer:
>
> 64 bytes from 10.1.0.3: icmp_seq=149 ttl=64 time=62.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=150 ttl=64 time=64.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=151 ttl=64 time=85.9 ms
> 64 bytes from 10.1.0.3: icmp_seq=152 ttl=64 time=80.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=153 ttl=64 time=132.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=154 ttl=64 time=64.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=155 ttl=64 time=128.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=156 ttl=64 time=116.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=157 ttl=64 time=120.5 ms
> 64 bytes from 10.1.0.3: icmp_seq=158 ttl=64 time=240.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=159 ttl=64 time=111.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=160 ttl=64 time=382.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=161 ttl=64 time=912.6 ms
> 64 bytes from 10.1.0.3: icmp_seq=162 ttl=64 time=1612.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=163 ttl=64 time=4373.6 ms
> 64 bytes from 10.1.0.3: icmp_seq=164 ttl=64 time=5128.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=165 ttl=64 time=7191.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=166 ttl=64 time=9473.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=167 ttl=64 time=8469.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=168 ttl=64 time=10040.7 ms
> 64 bytes from 10.1.0.3: icmp_seq=169 ttl=64 time=9036.7 ms
> 64 bytes from 10.1.0.3: icmp_seq=170 ttl=64 time=10681.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=171 ttl=64 time=9677.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=172 ttl=64 time=8673.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=173 ttl=64 time=10685.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=174 ttl=64 time=9681.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=175 ttl=64 time=8677.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=176 ttl=64 time=11997.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=177 ttl=64 time=10993.4 ms
> 64 bytes from 10.1.0.3: icmp_seq=178 ttl=64 time=9989.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=179 ttl=64 time=13797.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=180 ttl=64 time=12793.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=181 ttl=64 time=11789.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=182 ttl=64 time=10784.9 ms
> 64 bytes from 10.1.0.3: icmp_seq=183 ttl=64 time=9781.1 ms
>
> Netdev watchdog complains a lot:
>
> Oct 22 18:53:57 amd pand[2439]: Bluetooth PAN daemon version 2.19
> Oct 22 18:53:57 amd pand[2439]: Connecting to <won't tell you>
> Oct 22 18:53:58 amd pand[2439]: bnep0 connected
> Oct 22 18:54:37 amd kernel: usb 3-1: USB disconnect, address 2
> Oct 22 18:55:33 amd kernel: NETDEV WATCHDOG: bnep0: transmit timed out
> Oct 22 18:55:59 amd last message repeated 2 times
> Oct 22 18:56:51 amd last message repeated 5 times
> Oct 22 18:57:55 amd last message repeated 3 times
> Oct 22 18:59:03 amd last message repeated 7 times
>
> I use this to set up billionton:
>
> setserial /dev/ttyBT baud_base 921600
> hciattach -s 921600 /dev/ttyBT bcsp
>
> root@amd:~# tcpspray -n 1 -b 1000000 10.1.0.3
>
> Transmitted 1000000 bytes in 163.256781 seconds (5.982 kbytes/s)
>
> (okay, this was little slower, I was far from other side). Most tests
> look like this:
>
> root@amd:~# tcpspray -n 1 -b 1000000 10.1.0.3
>
> Transmitted 1000000 bytes in 103.183640 seconds (9.464 kbytes/s)
Pavel,
I see about the same with a bluetooth usb adapter. Suspect that is about what
you should see with bluetooth - its not designed for speed. It would be really
nice to be wrong though...
Ed Tomlinson
Hi!
> > I use this to set up billionton:
> >
> > setserial /dev/ttyBT baud_base 921600
> > hciattach -s 921600 /dev/ttyBT bcsp
> >
> > root@amd:~# tcpspray -n 1 -b 1000000 10.1.0.3
> >
> > Transmitted 1000000 bytes in 163.256781 seconds (5.982 kbytes/s)
> >
> > (okay, this was little slower, I was far from other side). Most tests
> > look like this:
> >
> > root@amd:~# tcpspray -n 1 -b 1000000 10.1.0.3
> >
> > Transmitted 1000000 bytes in 103.183640 seconds (9.464 kbytes/s)
>
> Pavel,
>
> I see about the same with a bluetooth usb adapter. Suspect that is about what
> you should see with bluetooth - its not designed for speed. It would be really
> nice to be wrong though...
No, it is designed to do more. It should do around ~100 kbytes/sec
according to spec, and MSI dongle *does* do 25 kbytes/sec easily
against nokia 6230.
Pavel
--
Thanks, Sharp!
Hi Pavel,
> Ping time is around 50msec, and that seems pretty much okay, but
> 10KB/sec seems like way too low.
>
> I am limited to 10KB/sec both on linux-to-linux bnetp transfers and it
> limits my transfer rates using edge and n6230, too :-(.
so you say that the Nokia 6230 has PAN Profile support and you don't
need any PPP crap to get Internet access? This would be the first phone
I have seen so far.
> Ping times during transfer:
>
> 64 bytes from 10.1.0.3: icmp_seq=149 ttl=64 time=62.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=150 ttl=64 time=64.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=151 ttl=64 time=85.9 ms
> 64 bytes from 10.1.0.3: icmp_seq=152 ttl=64 time=80.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=153 ttl=64 time=132.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=154 ttl=64 time=64.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=155 ttl=64 time=128.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=156 ttl=64 time=116.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=157 ttl=64 time=120.5 ms
> 64 bytes from 10.1.0.3: icmp_seq=158 ttl=64 time=240.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=159 ttl=64 time=111.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=160 ttl=64 time=382.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=161 ttl=64 time=912.6 ms
> 64 bytes from 10.1.0.3: icmp_seq=162 ttl=64 time=1612.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=163 ttl=64 time=4373.6 ms
> 64 bytes from 10.1.0.3: icmp_seq=164 ttl=64 time=5128.8 ms
> 64 bytes from 10.1.0.3: icmp_seq=165 ttl=64 time=7191.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=166 ttl=64 time=9473.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=167 ttl=64 time=8469.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=168 ttl=64 time=10040.7 ms
> 64 bytes from 10.1.0.3: icmp_seq=169 ttl=64 time=9036.7 ms
> 64 bytes from 10.1.0.3: icmp_seq=170 ttl=64 time=10681.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=171 ttl=64 time=9677.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=172 ttl=64 time=8673.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=173 ttl=64 time=10685.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=174 ttl=64 time=9681.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=175 ttl=64 time=8677.0 ms
> 64 bytes from 10.1.0.3: icmp_seq=176 ttl=64 time=11997.2 ms
> 64 bytes from 10.1.0.3: icmp_seq=177 ttl=64 time=10993.4 ms
> 64 bytes from 10.1.0.3: icmp_seq=178 ttl=64 time=9989.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=179 ttl=64 time=13797.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=180 ttl=64 time=12793.3 ms
> 64 bytes from 10.1.0.3: icmp_seq=181 ttl=64 time=11789.1 ms
> 64 bytes from 10.1.0.3: icmp_seq=182 ttl=64 time=10784.9 ms
> 64 bytes from 10.1.0.3: icmp_seq=183 ttl=64 time=9781.1 ms
The initial pings look good, the rest is very bad.
> Netdev watchdog complains a lot:
>
> Oct 22 18:53:57 amd pand[2439]: Bluetooth PAN daemon version 2.19
> Oct 22 18:53:57 amd pand[2439]: Connecting to <won't tell you>
> Oct 22 18:53:58 amd pand[2439]: bnep0 connected
> Oct 22 18:54:37 amd kernel: usb 3-1: USB disconnect, address 2
> Oct 22 18:55:33 amd kernel: NETDEV WATCHDOG: bnep0: transmit timed out
> Oct 22 18:55:59 amd last message repeated 2 times
> Oct 22 18:56:51 amd last message repeated 5 times
> Oct 22 18:57:55 amd last message repeated 3 times
> Oct 22 18:59:03 amd last message repeated 7 times
The transmit timeouts shouldn't be there. The question is now which side
is at fault. The host or the phone?
Please do a "hcitool info <won't tell you>" as root so I can see which
what chip we are dealing. Also "hciconfig hci0 version" for your card
would help.
You can also use "hcidump -X -V" to analyze the traffic.
Regards
Marcel
Hi!
> > Ping time is around 50msec, and that seems pretty much okay, but
> > 10KB/sec seems like way too low.
> >
> > I am limited to 10KB/sec both on linux-to-linux bnetp transfers and it
> > limits my transfer rates using edge and n6230, too :-(.
>
> so you say that the Nokia 6230 has PAN Profile support and you don't
> need any PPP crap to get Internet access? This would be the first phone
> I have seen so far.
No, sorry, that was over ppp over rfcomm. With MSI dongle, I get
25KB/sec with n6230. With bluetooth CF card, I only get 10KB/sec.
> > 64 bytes from 10.1.0.3: icmp_seq=181 ttl=64 time=11789.1 ms
> > 64 bytes from 10.1.0.3: icmp_seq=182 ttl=64 time=10784.9 ms
> > 64 bytes from 10.1.0.3: icmp_seq=183 ttl=64 time=9781.1 ms
>
> The initial pings look good, the rest is very bad.
Rest is during transfer. I'd expect it to be slightly worse, but not
that bad.
> > Netdev watchdog complains a lot:
> >
> > Oct 22 18:53:57 amd pand[2439]: Bluetooth PAN daemon version 2.19
> > Oct 22 18:53:57 amd pand[2439]: Connecting to <won't tell you>
> > Oct 22 18:53:58 amd pand[2439]: bnep0 connected
> > Oct 22 18:54:37 amd kernel: usb 3-1: USB disconnect, address 2
> > Oct 22 18:55:33 amd kernel: NETDEV WATCHDOG: bnep0: transmit timed out
> > Oct 22 18:55:59 amd last message repeated 2 times
> > Oct 22 18:56:51 amd last message repeated 5 times
> > Oct 22 18:57:55 amd last message repeated 3 times
> > Oct 22 18:59:03 amd last message repeated 7 times
>
> The transmit timeouts shouldn't be there. The question is now which side
> is at fault. The host or the phone?
This is against second linux box... Can't be the phone.
> Please do a "hcitool info <won't tell you>" as root so I can see which
> what chip we are dealing. Also "hciconfig hci0 version" for your card
> would help.
On billionton card:
root@spitz:/bt# hcitool info <address of MSI card>
Requesting information ...
BD Address: <address of MSI card>
Device Name: BlueZ (0)
LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
<power control> <transparent SCO>
root@spitz:/bt# hciconfig hci0 version
hci0: Type: UART
BD Address: <address of billionton> ACL MTU: 192:8 SCO MTU: 64:8
HCI Ver: 1.1 (0x1) HCI Rev: 0x33c LMP Ver: 1.1 (0x1) LMP Subver: 0x33c
Manufacturer: Cambridge Silicon Radio (10)
root@spitz:/bt#
On MSI side:
root@bug:~# hcitool info <address of billionton>
Requesting information ...
BD Address: <address of billionton>
Device Name: billionton
LMP Version: 1.1 (0x1) LMP Subversion: 0x33c
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
<power control> <transparent SCO>
root@bug:~#
> You can also use "hcidump -X -V" to analyze the traffic.
Do you prefer hcidump on MSI or on billionton side? On MSI side it is
easy to get, but it is generating *big* logs.
Pavel
--
Thanks, Sharp!
Hi Pavel,
> > > Ping time is around 50msec, and that seems pretty much okay, but
> > > 10KB/sec seems like way too low.
> > >
> > > I am limited to 10KB/sec both on linux-to-linux bnetp transfers and it
> > > limits my transfer rates using edge and n6230, too :-(.
> >
> > so you say that the Nokia 6230 has PAN Profile support and you don't
> > need any PPP crap to get Internet access? This would be the first phone
> > I have seen so far.
>
> No, sorry, that was over ppp over rfcomm. With MSI dongle, I get
> 25KB/sec with n6230. With bluetooth CF card, I only get 10KB/sec.
show me the "hcitool info ..." for the phone.
> > > 64 bytes from 10.1.0.3: icmp_seq=181 ttl=64 time=11789.1 ms
> > > 64 bytes from 10.1.0.3: icmp_seq=182 ttl=64 time=10784.9 ms
> > > 64 bytes from 10.1.0.3: icmp_seq=183 ttl=64 time=9781.1 ms
> >
> > The initial pings look good, the rest is very bad.
>
> Rest is during transfer. I'd expect it to be slightly worse, but not
> that bad.
>
> > > Netdev watchdog complains a lot:
> > >
> > > Oct 22 18:53:57 amd pand[2439]: Bluetooth PAN daemon version 2.19
> > > Oct 22 18:53:57 amd pand[2439]: Connecting to <won't tell you>
> > > Oct 22 18:53:58 amd pand[2439]: bnep0 connected
> > > Oct 22 18:54:37 amd kernel: usb 3-1: USB disconnect, address 2
> > > Oct 22 18:55:33 amd kernel: NETDEV WATCHDOG: bnep0: transmit timed out
> > > Oct 22 18:55:59 amd last message repeated 2 times
> > > Oct 22 18:56:51 amd last message repeated 5 times
> > > Oct 22 18:57:55 amd last message repeated 3 times
> > > Oct 22 18:59:03 amd last message repeated 7 times
> >
> > The transmit timeouts shouldn't be there. The question is now which side
> > is at fault. The host or the phone?
>
> This is against second linux box... Can't be the phone.
>From Linux to Linux you can get something around 80KB/sec. Do you have
any other USB dongle to test this against, because I think the PCMCIA
card is the problematic part here.
If you go over RFCOMM to the phone you will almost never reach the full
speed, because most RFCOMM implementation on the phones are not really
good. The PPP is eating the rest of the bandwidth.
Regards
Marcel
Hi!
> > > so you say that the Nokia 6230 has PAN Profile support and you don't
> > > need any PPP crap to get Internet access? This would be the first phone
> > > I have seen so far.
> >
> > No, sorry, that was over ppp over rfcomm. With MSI dongle, I get
> > 25KB/sec with n6230. With bluetooth CF card, I only get 10KB/sec.
>
> show me the "hcitool info ..." for the phone.
Sorry, I do not have it here just now. Should be able to get it in a
few days.
> > > > Netdev watchdog complains a lot:
> > > >
> > > > Oct 22 18:53:57 amd pand[2439]: Bluetooth PAN daemon version 2.19
> > > > Oct 22 18:53:57 amd pand[2439]: Connecting to <won't tell you>
> > > > Oct 22 18:53:58 amd pand[2439]: bnep0 connected
> > > > Oct 22 18:54:37 amd kernel: usb 3-1: USB disconnect, address 2
> > > > Oct 22 18:55:33 amd kernel: NETDEV WATCHDOG: bnep0: transmit timed out
> > > > Oct 22 18:55:59 amd last message repeated 2 times
> > > > Oct 22 18:56:51 amd last message repeated 5 times
> > > > Oct 22 18:57:55 amd last message repeated 3 times
> > > > Oct 22 18:59:03 amd last message repeated 7 times
> > >
> > > The transmit timeouts shouldn't be there. The question is now which side
> > > is at fault. The host or the phone?
> >
> > This is against second linux box... Can't be the phone.
>
> >From Linux to Linux you can get something around 80KB/sec. Do you have
> any other USB dongle to test this against, because I think the PCMCIA
> card is the problematic part here.
I agree that pcmcia card is problematic. No, I do not have any other
usb dongles, but...
billionton.n6230: 10KB/sec (ppp over rfcomm)
MSI..n6230: 25KB/sec (ppp over rfcomm)
MSI..billionton: 10KB/sec (bnetp)
...pretty much tells the story. I could do some obex transfers against
k700 to test it a bit more.
> If you go over RFCOMM to the phone you will almost never reach the full
> speed, because most RFCOMM implementation on the phones are not really
> good. The PPP is eating the rest of the bandwidth.
Fortunately edge has limit of 25KB/sec or something like that, and
bluetooth has 100KB/sec limit, so it is fast enough even with some
added overhead.
Pavel
--
Thanks, Sharp!
On Sunday 23 October 2005 04:35, Pavel Machek wrote:
> > > Transmitted 1000000 bytes in 103.183640 seconds (9.464 kbytes/s)
> >
> > I see about the same with a bluetooth usb adapter. ?Suspect that is about what
> > you should see with bluetooth - its not designed for speed. ?It would be really
> > nice to be wrong though...
>
> No, it is designed to do more. It should do around ~100 kbytes/sec
> according to spec, and MSI dongle *does* do 25 kbytes/sec easily
> against nokia 6230.
Pavel,
Then the interesting test is to see if the delay is kernel or phone. Are you talking
to the same phone with both adapters? If so please copy me on any test patches as
I too have the same issue when talking to a pilot T3 using rfcomm using a "0a12:0001
Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" usb dongle.
I would _love_ to get 25K/s
Thanks,
Ed Tomlinson
Hi!
> > > > Transmitted 1000000 bytes in 103.183640 seconds (9.464 kbytes/s)
> > >
> > > I see about the same with a bluetooth usb adapter. ?Suspect that is about what
> > > you should see with bluetooth - its not designed for speed. ?It would be really
> > > nice to be wrong though...
> >
> > No, it is designed to do more. It should do around ~100 kbytes/sec
> > according to spec, and MSI dongle *does* do 25 kbytes/sec easily
> > against nokia 6230.
>
> Pavel,
>
> Then the interesting test is to see if the delay is kernel or phone. Are you talking
> to the same phone with both adapters? If so please copy me on any test patches as
> I too have the same issue when talking to a pilot T3 using rfcomm using a "0a12:0001
> Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" usb dongle.
>
> I would _love_ to get 25K/s
Yes, I was using same phone (n6230) with MSI and billiontonCF. It gets
25KB/sec with MSI, but only 10KB/sec with billiontonCF.
Pavel
--
Thanks, Sharp!