[BT] slow file transfer

Bug Reports
1

REPRODUCIBILITY: 100%
OS VERSION: 4.5.0.18, Ubuntu 20.04 with all latest updates
HARDWARE: Xperia 10
UI LANGUAGE: PL
REGRESSION: No idea

DESCRIPTION:

while sending files through BT from computer to SFOS, transfer speed is very low compared to other phones

PRECONDITIONS:

just one or many png files with size around 600KB or more

STEPS TO REPRODUCE:

  1. Prepare several png image files
  2. Pair SFOS with computer
  3. send a file from computer to SFOS
  4. repeat steps 1-3 few times to get reasonable statistics

EXPECTED RESULT:

transfer should be at least 100kbps or even more

ACTUAL RESULT:

transfer starts from 50kbps and goes down to even 9kbps at the end of the file

MODIFICATIONS:

patchmanager

ADDITIONAL INFORMATION:

compared with LineageOS test phone, where transfer were between 100kbps up to 400kbps.

2 Likes
2

Hi, I reported this some time ago (Nov 21).

3 Likes
3

let’s hope someone will fix this. Cause slow file sending connected with inability to transfer multiple files at once means it’s painful to use BT

4

In fact I do not understand why you mean multiple files?
And how do you send multiple images? Is it something new on 4.5.0.18?

IMO it is slow on each file as it writes only 666bytes at a time (actually it seems the phone is sending the file in very small peaces), while from another phone it was sending chunks of 32K.
However now I checked one Android phone, which is sending also around 600bytes at a time.

Of course the other thing is the size of the images

5

Anyone familiar with how MTU is set in OBEX?

Because a cursory look at the bluez5/obex source seems to define the default to 32k. Is there some kind of MTU discovery or negotiation between devices?

Edit: While this is talking about BLE, it still is instructive:

1 Like
6

Thanks for pointing this out. Generally I copy paste the steps from my other bug report and also it’s about sending files from Computer to SFOS not the other way around which is by default impossible with SFOS except you’ll install my patch:
https://coderus.openrepos.net/pm2/project/GallerySharing
But even after doing that, there’s still a bug in SFOS that needs to be fixed:

maybe it’s a HW limitation then, but it would be very odd since there’s at least BT 5.0 on Xperia 10.

7 
$ grep -A2 MTU /etc/bluetooth/main.conf

# Exchange MTU size.
# Possible values: 23-517
# Defaults to 517
#ExchangeMTU = 517

# Number of ATT channels

Don’t know, maybe setting that in the conf file will improve things?

8

but default is already 517.

9

I was looking into obexd at the time I came across this issue. And I do not remember how I measured the size exactly, but my use case was copy files from the phone to the PC via obexd. I then tried the same with the old N9 and it was mind blowing 32K. So how could it be that the older N9 hardware had higher output rate?
I am starting to think that it is either configuration as you suggested or some bug somewhere that affects more modern devices for some reason.

10

well I also tested this against very old phone and as I mentioned, there I could get up to 500kbps.

11

thanks for the update and information provided. This is very interesting.
How did you measure the transfer speed?

12

well I observed the transfer info on Ubuntu, now I think I could by mistake use wrong units but there was still difference between lineageos and sfos were on Lineage it was between 100 and 500 while on SFOS it was from 56 down to 9. :confused: So even with wrong units, there’s clearly a problem.

13

What means “I observed”?

Also are you trying this with same file (same file size) or just random file?

Best if we could use same set for testing

  • same file (same size)
  • kind of measurement - time function or so.

I’ll try to do this here. But my impression also without having exact numbers and using different files, is that the small size causes overhead that results in a longer transfer time.

I am posting those results in the other post

BR

14

yes I used the same file. And yes I was observing the Transfer dialog window in ubuntu which was showing the actual progress and speed. In the report the file size I mentioned was around 600KB.

15

Hi, thanks for the information and sorry if I repeat myself.
You mentioned you tested with lineageos and it was 100 and 500.
Can you start the obex daemon as I posted in the other thread, so that we have the similar log information as shown there. That would be great.

Also I think your finding here, confirm my findings in the other thread and we can conclude that the issue must be in Sailfish OS somewhere, but as I mentioned I observed similar rates from Android to the same PC. If I find time in the next couple of days, I will try to capture the full debug from all 3 phones with one and the same file transferred to one and the same PC.

16

ok checked and when sending file from SFOS it’s 666 for LineageOS it’s 584 but please keep in mind that this bug is about sending files from PC to SFOS not the other way around.

17

Oh, thanks for reminding me,
so the conclusion is, it is behaving the same in both directions … but then it should be something outside of Sailfish OS.
What is your Ubuntu and the kernel version?
I am sure the Nokia N9 had a 3.x kernel.
may be the issue is somewhere low down the chain.

18

Version of Ubuntu which was used for testing is in the report but here: 20.04 and 5.15 it’s LTS,