Hi,all,
the following is my test result in a real machine:
Memory: 1G DDR 533
Hard Disk: 5400ת 8M cache
CPU: PM 1.86G 2M cache
==OS: suse 10.1
==kernel 2.6.16.13-4 and 2.6.18
==Files: 2 file,one is 1M, the other is 77k
==Bluetooth OBEX Object Push client (0.99 beta1) to push file
==result:
Ave. time
Kernel 2.6.16
Kernel 2.6.18
First File (1M)
68 s
115 s
Second File (77k)
5 s
9 s
~15Kps in 2.6.16
~8.5Kps in 2.6.18
still slower.
2006/10/9, Mingfan. Lu <[email protected]>: - ??ʾ???????? -
--
With respects,
Mingfan.Lu
Am Donnerstag, den 19.10.2006, 16:07 +0800 schrieb Mingfan.Lu:
> I don't know whether the config make it happen or there is something
> wrong with it?
> So, Martin, How about you make config when you building your new
> kernel?
I build the kernels the "debian way" cause I use Ubuntu as well. So
basically:
(1) tar xjf linux-2.6.18.x.tar.bz2
(2) cd linux-2.6.18.x
(3) patch -p1 < ../patch-2.6.18-mh6
(4) cp /boot/config-2.6.15-26-686 .config
(5) make oldconfig
[edit some config options manually if necessary]
(6) fakeroot make-kpkg kernel_image modules_image --initrd --revision
mh6 binary
(7) cd ..
(8) dpkg -i kernel-image-2.6.18.xmh6_i386.deb
Edit /boot/grub/menu.lst if necessary and that's it.
Your problems are really strange. How do you measure the time? I don't
think it has anything to do with the config file per se. But I know of
some pretty neat and improved debugging facilities -- maybe you want to
check out that there is nothing in action that slows down the machine
just for the purpose of deadlock detections.
I'm sorry about it, but it seems extremely hard to me locating such a
problem that never affects one of my machines. :-/
Good luck,
Martin
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi, Martin,
Thank you for you nice help.
I retest it in a ubuntu machine (kernel version 2.6.15), bluez lib's
version is 2.24
Then I rebuilt 2.6.18 in the ubuntu machine.
I still found that 2.6.18 is much slower than 2.6.15 when pushing obex over
bluez.
when I rebuit 2.6.18 in the 2.6.15 kernel machine:
make mrproper
make oldconfig (use default value for every new config)
make
make modules_install
make install
mkinitramfs -o /boot/initrd.img-2.6.18 2.6.18
I don't know whether the config make it happen or there is something wrong
with it?
So, Martin, How about you make config when you building your new kernel?
Thanks very much.
==============================================
2006/10/16, Martin R?hricht <[email protected]>:
>
> Am Montag, den 16.10.2006, 13:25 +0800 schrieb Mingfan.Lu:
> > the following is my test result in a real machine:
> > [...]
>
> Okay, due to your tenacious demand, I compiled and installed a plain
> 2.6.18.1 vanilla kernel as well as a 2.6.18.1 kernel with the latest
> -mh5 patch applied.
> I will show you my test results for two files, the first being 1376034
> bytes (1,31MB) in size and the second being 2397995 bytes (2,29MB) in
> size.
> Let me at first mention the results that I got. I didn't encounter any
> slowness by using a 2.6.18.1 vanilla kernel. However it looks like the
> newly introduced and applied flow control may slow down the transfer
> speed. But be aware that (L2CAP) flow control mode is in action only by
> using two Linux kernels that have one of the latest -mh* patches
> applied! This mode is not(!) used by transmission between a Linux
> computer and another one that uses a proprietary Bluetooth software
> stack (even if the new Symbian OS may be able to use flow control mode,
> too), or say two Linux computers of which one has a kernel without this
> new patch applied.
> You didn't specify your exact settings -> did you apply one of the
> latest -mh* patches to you 2.6.18 kernel or not? Which computers did you
> use (one is the Linux computer but who is the other one)?
>
> So here are my results. The first three tests were done between a Linux
> computer and an Apple iMac G4 with the Apple Bluetooth stack that comes
> with Mac OS X 10.4:
>
> Test with kernel 2.6.18.1 and Apple Bluetooth Stack:
> Retrieval:
> 1376034 bytes -> 58 sec -> 23KB/s
> 2397995 bytes -> 95 sec -> 25KB/s
>
> Transmission:
> 1376034 bytes -> 42 sec -> 32KB/s
> 2397995 bytes -> 73 sec -> 32KB/s
>
>
> Test with kernel 2.6.15 (Ubuntu Dapper Drake) and Apple Bluetooth Stack:
> Retrieval:
> 1376034 bytes -> 57 sec -> 24KB/s
> 2397995 bytes -> 99 sec -> 24KB/s
>
> Transmission:
> 1376034 bytes -> 46 sec -> 29KB/s
> 2397995 bytes -> 77 sec -> 30KB/s
>
>
> Test with kernel 2.6.18.1-mh5 and Apple Bluetooth Stack:
> Retrieval:
> 1376034 bytes -> 54 sec -> 25KB/s
> 2397995 bytes -> 94 sec -> 25KB/s
>
> Transmission:
> 1376034 bytes -> 43 sec -> 31KB/s
> 2397995 bytes -> 73 sec -> 32KB/s
>
>
> ------------(now between two Linux computers)---------
> Test with kernel 2.6.18.1-mh5 to kernel 2.6.18.1-mh5
> Retrieval:
> 1376034 bytes -> 88 sec -> 15KB/s
> 2397995 bytes -> 154 sec -> 15KB/s
>
> Transmission:
> 1376034 bytes -> 82 sec -> 16KB/s
> 2397995 bytes -> 140 sec -> 17KB/s
>
>
> Test with kernel 2.6.18.1-mh5 to kernel 2.6.15 (Ubuntu Dapper Drake)
> Retrieval:
> 1376034 bytes -> 57 sec -> 24KB/s
> 2397995 bytes -> 99 sec -> 24KB/s
>
> Transmission:
> 1376034 bytes -> 68 sec -> 20KB/s
> 2397995 bytes -> 114 sec -> 21KB/s
>
>
> As you can see -- the transmission speed is quite constant between the
> same setups. Two things would need more investigations:
> (1) Why is it that a file transfer from Linux to Apple is faster than
> between two Linux entities?
> (2) Is it really L2CAP Flow Control Mode that slows down the connection
> with its protocol overhead?
>
> If Flow Control Mode really slows down the connection, we should try to
> implement a user interface to enable or disable this mode. But currently
> this is not urgent as no other device makes use of it.
>
> Martin
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
With respects,
Mingfan.Lu
Thanks for you nice help.
My target phone is Nokia E61.(Symbian 9.1 S60 3rd)
I didn't use any mh* for the 2.6.18,because I found that without/with mh*
are the same, both are slower than 2.6.16
so I only gave the result of 2.6.16 and 2.6.18.
I don't think L2cap flow control made the poor result in the 2.6.18 in my
tests.
Notice:
when I rebuilt the 2.6.18, I used the config which was used to build the 2.
6.16,
Is it possible that the config ?
2006/10/16, Martin R?hricht <[email protected]>:
>
> Am Montag, den 16.10.2006, 13:25 +0800 schrieb Mingfan.Lu:
> > the following is my test result in a real machine:
> > [...]
>
> Okay, due to your tenacious demand, I compiled and installed a plain
> 2.6.18.1 vanilla kernel as well as a 2.6.18.1 kernel with the latest
> -mh5 patch applied.
> I will show you my test results for two files, the first being 1376034
> bytes (1,31MB) in size and the second being 2397995 bytes (2,29MB) in
> size.
> Let me at first mention the results that I got. I didn't encounter any
> slowness by using a 2.6.18.1 vanilla kernel. However it looks like the
> newly introduced and applied flow control may slow down the transfer
> speed. But be aware that (L2CAP) flow control mode is in action only by
> using two Linux kernels that have one of the latest -mh* patches
> applied! This mode is not(!) used by transmission between a Linux
> computer and another one that uses a proprietary Bluetooth software
> stack (even if the new Symbian OS may be able to use flow control mode,
> too), or say two Linux computers of which one has a kernel without this
> new patch applied.
> You didn't specify your exact settings -> did you apply one of the
> latest -mh* patches to you 2.6.18 kernel or not? Which computers did you
> use (one is the Linux computer but who is the other one)?
>
> So here are my results. The first three tests were done between a Linux
> computer and an Apple iMac G4 with the Apple Bluetooth stack that comes
> with Mac OS X 10.4:
>
> Test with kernel 2.6.18.1 and Apple Bluetooth Stack:
> Retrieval:
> 1376034 bytes -> 58 sec -> 23KB/s
> 2397995 bytes -> 95 sec -> 25KB/s
>
> Transmission:
> 1376034 bytes -> 42 sec -> 32KB/s
> 2397995 bytes -> 73 sec -> 32KB/s
>
>
> Test with kernel 2.6.15 (Ubuntu Dapper Drake) and Apple Bluetooth Stack:
> Retrieval:
> 1376034 bytes -> 57 sec -> 24KB/s
> 2397995 bytes -> 99 sec -> 24KB/s
>
> Transmission:
> 1376034 bytes -> 46 sec -> 29KB/s
> 2397995 bytes -> 77 sec -> 30KB/s
>
>
> Test with kernel 2.6.18.1-mh5 and Apple Bluetooth Stack:
> Retrieval:
> 1376034 bytes -> 54 sec -> 25KB/s
> 2397995 bytes -> 94 sec -> 25KB/s
>
> Transmission:
> 1376034 bytes -> 43 sec -> 31KB/s
> 2397995 bytes -> 73 sec -> 32KB/s
>
>
> ------------(now between two Linux computers)---------
> Test with kernel 2.6.18.1-mh5 to kernel 2.6.18.1-mh5
> Retrieval:
> 1376034 bytes -> 88 sec -> 15KB/s
> 2397995 bytes -> 154 sec -> 15KB/s
>
> Transmission:
> 1376034 bytes -> 82 sec -> 16KB/s
> 2397995 bytes -> 140 sec -> 17KB/s
>
>
> Test with kernel 2.6.18.1-mh5 to kernel 2.6.15 (Ubuntu Dapper Drake)
> Retrieval:
> 1376034 bytes -> 57 sec -> 24KB/s
> 2397995 bytes -> 99 sec -> 24KB/s
>
> Transmission:
> 1376034 bytes -> 68 sec -> 20KB/s
> 2397995 bytes -> 114 sec -> 21KB/s
>
>
> As you can see -- the transmission speed is quite constant between the
> same setups. Two things would need more investigations:
> (1) Why is it that a file transfer from Linux to Apple is faster than
> between two Linux entities?
> (2) Is it really L2CAP Flow Control Mode that slows down the connection
> with its protocol overhead?
>
> If Flow Control Mode really slows down the connection, we should try to
> implement a user interface to enable or disable this mode. But currently
> this is not urgent as no other device makes use of it.
>
> Martin
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
With respects,
Mingfan.Lu
Am Montag, den 16.10.2006, 13:25 +0800 schrieb Mingfan.Lu:
> the following is my test result in a real machine:
> [...]
Okay, due to your tenacious demand, I compiled and installed a plain
2.6.18.1 vanilla kernel as well as a 2.6.18.1 kernel with the latest
-mh5 patch applied.
I will show you my test results for two files, the first being 1376034
bytes (1,31MB) in size and the second being 2397995 bytes (2,29MB) in
size.
Let me at first mention the results that I got. I didn't encounter any
slowness by using a 2.6.18.1 vanilla kernel. However it looks like the
newly introduced and applied flow control may slow down the transfer
speed. But be aware that (L2CAP) flow control mode is in action only by
using two Linux kernels that have one of the latest -mh* patches
applied! This mode is not(!) used by transmission between a Linux
computer and another one that uses a proprietary Bluetooth software
stack (even if the new Symbian OS may be able to use flow control mode,
too), or say two Linux computers of which one has a kernel without this
new patch applied.
You didn't specify your exact settings -> did you apply one of the
latest -mh* patches to you 2.6.18 kernel or not? Which computers did you
use (one is the Linux computer but who is the other one)?
So here are my results. The first three tests were done between a Linux
computer and an Apple iMac G4 with the Apple Bluetooth stack that comes
with Mac OS X 10.4:
Test with kernel 2.6.18.1 and Apple Bluetooth Stack:
Retrieval:
1376034 bytes -> 58 sec -> 23KB/s
2397995 bytes -> 95 sec -> 25KB/s
Transmission:
1376034 bytes -> 42 sec -> 32KB/s
2397995 bytes -> 73 sec -> 32KB/s
Test with kernel 2.6.15 (Ubuntu Dapper Drake) and Apple Bluetooth Stack:
Retrieval:
1376034 bytes -> 57 sec -> 24KB/s
2397995 bytes -> 99 sec -> 24KB/s
Transmission:
1376034 bytes -> 46 sec -> 29KB/s
2397995 bytes -> 77 sec -> 30KB/s
Test with kernel 2.6.18.1-mh5 and Apple Bluetooth Stack:
Retrieval:
1376034 bytes -> 54 sec -> 25KB/s
2397995 bytes -> 94 sec -> 25KB/s
Transmission:
1376034 bytes -> 43 sec -> 31KB/s
2397995 bytes -> 73 sec -> 32KB/s
------------(now between two Linux computers)---------
Test with kernel 2.6.18.1-mh5 to kernel 2.6.18.1-mh5
Retrieval:
1376034 bytes -> 88 sec -> 15KB/s
2397995 bytes -> 154 sec -> 15KB/s
Transmission:
1376034 bytes -> 82 sec -> 16KB/s
2397995 bytes -> 140 sec -> 17KB/s
Test with kernel 2.6.18.1-mh5 to kernel 2.6.15 (Ubuntu Dapper Drake)
Retrieval:
1376034 bytes -> 57 sec -> 24KB/s
2397995 bytes -> 99 sec -> 24KB/s
Transmission:
1376034 bytes -> 68 sec -> 20KB/s
2397995 bytes -> 114 sec -> 21KB/s
As you can see -- the transmission speed is quite constant between the
same setups. Two things would need more investigations:
(1) Why is it that a file transfer from Linux to Apple is faster than
between two Linux entities?
(2) Is it really L2CAP Flow Control Mode that slows down the connection
with its protocol overhead?
If Flow Control Mode really slows down the connection, we should try to
implement a user interface to enable or disable this mode. But currently
this is not urgent as no other device makes use of it.
Martin
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Martin,
I have done some tests like you mentioned.
A real machine (P4 3.0G+1G RAM)
Debian Linux (original kernel 2.6.8)
Bluez 3.6
I have rebuilt the kernels in debian way:
2.6.16.13-4 from opensuse 10.1
2.6.17 from kernel.org
2.6.18 from kernel org
2.6.18-mh7 (with the patch mh7 from
bluez)
The speed of OBEX is similar, but still low. about 5Kps. < 15~30 Kps (Your
results.)
I don't know why.
The configure?
Could you give me your .config file when you build the kernel.
Thank you very much.
2006/10/20, Martin R?hricht <[email protected]>:
>
> Am Donnerstag, den 19.10.2006, 16:07 +0800 schrieb Mingfan.Lu:
>
> > I don't know whether the config make it happen or there is something
> > wrong with it?
> > So, Martin, How about you make config when you building your new
> > kernel?
>
> I build the kernels the "debian way" cause I use Ubuntu as well. So
> basically:
> (1) tar xjf linux-2.6.18.x.tar.bz2
> (2) cd linux-2.6.18.x
> (3) patch -p1 < ../patch-2.6.18-mh6
> (4) cp /boot/config-2.6.15-26-686 .config
> (5) make oldconfig
> [edit some config options manually if necessary]
> (6) fakeroot make-kpkg kernel_image modules_image --initrd --revision
> mh6 binary
> (7) cd ..
> (8) dpkg -i kernel-image-2.6.18.xmh6_i386.deb
>
> Edit /boot/grub/menu.lst if necessary and that's it.
> Your problems are really strange. How do you measure the time? I don't
> think it has anything to do with the config file per se. But I know of
> some pretty neat and improved debugging facilities -- maybe you want to
> check out that there is nothing in action that slows down the machine
> just for the purpose of deadlock detections.
>
> I'm sorry about it, but it seems extremely hard to me locating such a
> problem that never affects one of my machines. :-/
>
> Good luck,
> Martin
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
With respects,
Mingfan.Lu