Home of the Squeezebox™ & Transporter® network music players.
Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 50
  1. #21
    Senior Member mr-b's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    429
    I managed to do some network tests.
    I found that no matter what cable or network port, the network on the RPi4 always takes longer than the Rpi3 at boot time to do whatever it's waiting for (maybe DHCP renew?), entries always look like this:

    Waiting for network................ Done (16).

    After that I did some iperf tests (via Diags, Network, Network Perf) and was surprised to see that the max I could obtain was 300Mbps.
    Lots of swapping cables, ports etc. later could not get this to change, and it matches what the Rpi3 can do.
    I was using iperf in Download mode using TCP on both PCP clients with the Windows boxes as servers.

    Code:
    [ WARN ] Squeezelite is running, results might be affected
    [ WARN ] Goto Main menu and stop squeezelite
    [ INFO ] Iperf running in TCP Mode.
    [ INFO ] Iperf running in Receive Mode.
    [ INFO ] Iperf will run for 20 seconds, then output will show.......
    iperf 3.6
    Linux PCP-XLR 4.19.122-pcpCore_v8 #1 SMP PREEMPT Tue May 26 20:10:39 EDT 2020 aarch64
    Control connection MSS 1460
    Time: Tue, 30 Jun 2020 14:15:43 GMT
    Connecting to host 192.168.1.105, port 5201
    Reverse mode, remote host 192.168.1.105 is sending
          Cookie: ksidzafode2ewcqlwi7h6yxwfxp7buuetkev
          TCP MSS: 1460 (default)
    [  5] local 192.168.1.184 port 56022 connected to 192.168.1.105 port 5201
    Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 20 second test, tos 0
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-1.00   sec  34.2 MBytes   287 Mbits/sec                  
    [  5]   1.00-2.00   sec  36.3 MBytes   304 Mbits/sec                  
    [  5]   2.00-3.00   sec  36.1 MBytes   303 Mbits/sec                  
    [  5]   3.00-4.00   sec  36.3 MBytes   304 Mbits/sec                  
    [  5]   4.00-5.00   sec  35.3 MBytes   296 Mbits/sec                  
    [  5]   5.00-6.00   sec  35.6 MBytes   299 Mbits/sec                  
    [  5]   6.00-7.00   sec  34.1 MBytes   286 Mbits/sec                  
    [  5]   7.00-8.00   sec  37.5 MBytes   314 Mbits/sec                  
    [  5]   8.00-9.00   sec  35.2 MBytes   295 Mbits/sec                  
    [  5]   9.00-10.00  sec  35.3 MBytes   296 Mbits/sec                  
    [  5]  10.00-11.00  sec  36.6 MBytes   307 Mbits/sec                  
    [  5]  11.00-12.00  sec  34.9 MBytes   293 Mbits/sec                  
    [  5]  12.00-13.00  sec  35.2 MBytes   296 Mbits/sec                  
    [  5]  13.00-14.00  sec  37.5 MBytes   314 Mbits/sec                  
    [  5]  14.00-15.00  sec  36.0 MBytes   302 Mbits/sec                  
    [  5]  15.00-16.00  sec  35.6 MBytes   299 Mbits/sec                  
    [  5]  16.00-17.00  sec  34.8 MBytes   291 Mbits/sec                  
    [  5]  17.00-18.00  sec  35.5 MBytes   298 Mbits/sec                  
    [  5]  18.00-19.00  sec  37.1 MBytes   311 Mbits/sec                  
    [  5]  19.00-20.00  sec  34.3 MBytes   288 Mbits/sec                  
    - - - - - - - - - - - - - - - - - - - - - - - - -
    Test Complete. Summary Results:
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-20.00  sec   714 MBytes   299 Mbits/sec                  sender
    [  5]   0.00-20.00  sec   713 MBytes   299 Mbits/sec                  receiver
    CPU Utilization: local/receiver 24.7% (2.6%u/22.2%s), remote/sender 0.1% (0.0%u/0.1%s)
    rcv_tcp_congestion cubic
    
    iperf Done.
    I was using two different Windows target machines, and between them they can do GigE fine.

    Also I can't seem to find anything that will show what the LAN port speed is, ifconfig doesn't say and ethtool isn't present.
    Ifconfig did show there were no packet errors, however.

    Then I tried the iperf cmd via the cli directly, and got GigE speed!

    Code:
    $ iperf3 -c 192.168.1.105
    Connecting to host 192.168.1.105, port 5201
    [  5] local 192.168.1.184 port 56030 connected to 192.168.1.105 port 5201
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec   109 MBytes   913 Mbits/sec    0    217 KBytes
    [  5]   1.00-2.00   sec   108 MBytes   908 Mbits/sec    0    217 KBytes
    [  5]   2.00-3.00   sec   107 MBytes   898 Mbits/sec    0    217 KBytes
    [  5]   3.00-4.00   sec   110 MBytes   921 Mbits/sec    0    217 KBytes
    [  5]   4.00-5.00   sec   109 MBytes   912 Mbits/sec    0    217 KBytes
    [  5]   5.00-6.00   sec   108 MBytes   904 Mbits/sec    0    217 KBytes
    [  5]   6.00-7.00   sec   107 MBytes   901 Mbits/sec    0    217 KBytes
    [  5]   7.00-8.00   sec   110 MBytes   920 Mbits/sec    0    217 KBytes
    [  5]   8.00-9.00   sec   109 MBytes   911 Mbits/sec    0    217 KBytes
    [  5]   9.00-10.00  sec   109 MBytes   916 Mbits/sec    0    217 KBytes
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate         Retr
    [  5]   0.00-10.00  sec  1.06 GBytes   910 Mbits/sec    0             sender
    [  5]   0.00-10.00  sec  1.06 GBytes   910 Mbits/sec                  receiver
    
    iperf Done.
    So at least the port speed and perf is fine now, but what is the diff between the UI and CLI iperf cmds that's causing the speed diff?
    Last edited by mr-b; 2020-06-30 at 08:01.

  2. #22
    Senior Member Greg Erskine's Avatar
    Join Date
    Sep 2006
    Location
    Sydney, Australia
    Posts
    1,879
    pCP runs this:

    iperf3 -c $IP3_IP -p $IPERF_SERVER_PORT -V $UDP -b 300M $DURATION $REV

    where $DURATION = -t 21 -O 1

    so it has the "-b 300M" option and discards the first 1 second of data

  3. #23
    Senior Member mr-b's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    429
    Tx for the info.

    So why does it target 300Mbps bandwidth (-b option)?

  4. #24
    Senior Member Greg Erskine's Avatar
    Join Date
    Sep 2006
    Location
    Sydney, Australia
    Posts
    1,879
    Dunno

  5. #25
    Senior Member paul-'s Avatar
    Join Date
    Jan 2013
    Posts
    3,254
    Because at the time I wrote the routines, the RPI4 did not exist. The RPI3B+ could never reach true GB speed, If you push data from a GB capable machine to your pi it would flood the device. The network devices on the older pies do not handle being flooded all that well.
    piCorePlayer a small player for the Raspberry Pi in RAM.
    Homepage: https://www.picoreplayer.org

    Please donate if you like the piCorePlayer

  6. #26
    Senior Member mr-b's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    429
    Ok tx.

    It's odd though that the target bandwidth cmd switch wasn't visible in the output window, as then the smoking gun would been evident.
    Plus this is in receive mode so surely it wouldn't flood itself?


    Also RE: Waiting for network delay at boot time, I switched the Pi3 from static ip to DHCP and the Pi4 from DHCP to static, and the Pi4 result is down to a second (same as Pi3 with DHCP), so maybe it could be DHCP-related on the Pi4.

    Waiting for network. Done (1).

  7. #27
    Senior Member paul-'s Avatar
    Join Date
    Jan 2013
    Posts
    3,254
    If I recall, a process can flood the network too. Perhaps that has been fixed in newer kernels. How does your pi3 perform with and without the -b 300 setting? When it comes to audio, 300MBit is more than sufficient to stream audio, which is what we are really concerned about.
    piCorePlayer a small player for the Raspberry Pi in RAM.
    Homepage: https://www.picoreplayer.org

    Please donate if you like the piCorePlayer

  8. #28
    Senior Member mr-b's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    429
    Quote Originally Posted by paul- View Post
    If I recall, a process can flood the network too. Perhaps that has been fixed in newer kernels. How does your pi3 perform with and without the -b 300 setting? When it comes to audio, 300MBit is more than sufficient to stream audio, which is what we are really concerned about.
    For just pure streaming to players, yes, but actually I'm concerned about any network errors due to the odd behaviour noted before, plus my music library is stored on another machine, which will be retrieved using SMB/TCP on GigE, and stressing the system is one of the best ways of showing errors.

    So I compared iperf on UI vs CLI on a Pi3/6.0.0:

    UI:
    Code:
    [ WARN ] Squeezelite is running, results might be affected
    [ WARN ] Goto Main menu and stop squeezelite
    [ INFO ] Iperf running in TCP Mode.
    [ INFO ] Iperf running in Receive Mode.
    [ INFO ] Iperf will run for 20 seconds, then output will show.......
    iperf 3.6
    Linux Touch-pCP 4.19.105-pcpCore_v7 #1 SMP Sat Feb 22 00:32:02 EST 2020 armv7l
    Control connection MSS 1460
    Time: Wed, 01 Jul 2020 12:39:31 GMT
    Connecting to host 192.168.1.105, port 5201
    Reverse mode, remote host 192.168.1.105 is sending
          Cookie: xdc5lxnjjixno4h4vq6qqnu7m5nvf7hrufdc
          TCP MSS: 1460 (default)
    [  5] local 192.168.1.112 port 36136 connected to 192.168.1.105 port 5201
    Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 20 second test, tos 0
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-1.00   sec  35.6 MBytes   299 Mbits/sec                  
    [  5]   1.00-2.00   sec  34.2 MBytes   287 Mbits/sec                  
    [  5]   2.00-3.00   sec  37.0 MBytes   310 Mbits/sec                  
    [  5]   3.00-4.00   sec  35.3 MBytes   296 Mbits/sec                  
    [  5]   4.00-5.00   sec  37.0 MBytes   311 Mbits/sec                  
    [  5]   5.00-6.00   sec  35.8 MBytes   300 Mbits/sec                  
    [  5]   6.00-7.00   sec  34.0 MBytes   285 Mbits/sec                  
    [  5]   7.00-8.00   sec  37.5 MBytes   314 Mbits/sec                  
    [  5]   8.00-9.00   sec  34.1 MBytes   286 Mbits/sec                  
    [  5]   9.00-10.00  sec  36.4 MBytes   306 Mbits/sec                  
    [  5]  10.00-11.00  sec  36.9 MBytes   310 Mbits/sec                  
    [  5]  11.00-12.00  sec  33.5 MBytes   281 Mbits/sec                  
    [  5]  12.00-13.00  sec  36.3 MBytes   304 Mbits/sec                  
    [  5]  13.00-14.00  sec  37.3 MBytes   313 Mbits/sec                  
    [  5]  14.00-15.00  sec  35.8 MBytes   300 Mbits/sec                  
    [  5]  15.00-16.00  sec  35.7 MBytes   299 Mbits/sec                  
    [  5]  16.00-17.00  sec  34.9 MBytes   292 Mbits/sec                  
    [  5]  17.00-18.00  sec  34.7 MBytes   291 Mbits/sec                  
    [  5]  18.00-19.00  sec  38.1 MBytes   319 Mbits/sec                  
    [  5]  19.00-20.00  sec  33.8 MBytes   283 Mbits/sec                  
    - - - - - - - - - - - - - - - - - - - - - - - - -
    Test Complete. Summary Results:
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-20.00  sec   714 MBytes   299 Mbits/sec                  sender
    [  5]   0.00-20.00  sec   714 MBytes   299 Mbits/sec                  receiver
    CPU Utilization: local/receiver 35.5% (1.3%u/34.2%s), remote/sender 1.5% (0.2%u/1.4%s)
    rcv_tcp_congestion cubic
    
    iperf Done.

    CLI:
    Code:
    ~$ iperf3 -c 192.168.1.105
    Connecting to host 192.168.1.105, port 5201
    [  5] local 192.168.1.112 port 36140 connected to 192.168.1.105 port 5201
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec  34.2 MBytes   287 Mbits/sec    0    217 KBytes
    [  5]   1.00-2.00   sec  33.8 MBytes   284 Mbits/sec    0    217 KBytes
    [  5]   2.00-3.00   sec  31.9 MBytes   268 Mbits/sec    0    217 KBytes
    [  5]   3.00-4.00   sec  33.7 MBytes   282 Mbits/sec    0    217 KBytes
    [  5]   4.00-5.00   sec  33.7 MBytes   283 Mbits/sec    0    217 KBytes
    [  5]   5.00-6.00   sec  33.4 MBytes   280 Mbits/sec    0    217 KBytes
    [  5]   6.00-7.00   sec  33.9 MBytes   284 Mbits/sec    0    217 KBytes
    [  5]   7.00-8.00   sec  32.0 MBytes   268 Mbits/sec    0    217 KBytes
    [  5]   8.00-9.00   sec  33.7 MBytes   283 Mbits/sec    0    217 KBytes
    [  5]   9.00-10.00  sec  33.4 MBytes   281 Mbits/sec    0    217 KBytes
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate         Retr
    [  5]   0.00-10.00  sec   334 MBytes   280 Mbits/sec    0             sender
    [  5]   0.00-10.00  sec   333 MBytes   280 Mbits/sec                  receiver
    
    iperf Done.
    
    
    $ iperf3 -c 192.168.1.105 -b 300M
    Connecting to host 192.168.1.105, port 5201
    [  5] local 192.168.1.112 port 36156 connected to 192.168.1.105 port 5201
    [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
    [  5]   0.00-1.00   sec  32.4 MBytes   271 Mbits/sec    0    217 KBytes
    [  5]   1.00-2.00   sec  32.5 MBytes   273 Mbits/sec    0    217 KBytes
    [  5]   2.00-3.00   sec  33.5 MBytes   281 Mbits/sec    0    217 KBytes
    [  5]   3.00-4.00   sec  33.5 MBytes   281 Mbits/sec    0    217 KBytes
    [  5]   4.00-5.00   sec  33.6 MBytes   282 Mbits/sec    0    217 KBytes
    [  5]   5.00-6.00   sec  33.8 MBytes   283 Mbits/sec    0    217 KBytes
    [  5]   6.00-7.00   sec  32.9 MBytes   276 Mbits/sec    0    217 KBytes
    [  5]   7.00-8.00   sec  33.0 MBytes   277 Mbits/sec    0    217 KBytes
    [  5]   8.00-9.00   sec  33.6 MBytes   282 Mbits/sec    0    217 KBytes
    [  5]   9.00-10.00  sec  32.1 MBytes   269 Mbits/sec    0    217 KBytes
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate         Retr
    [  5]   0.00-10.00  sec   331 MBytes   278 Mbits/sec    0             sender
    [  5]   0.00-10.00  sec   331 MBytes   277 Mbits/sec                  receiver
    
    iperf Done.
    
    $ ifconfig -a
    eth0      Link encap:Ethernet  HWaddr B8:27:EB:CB:07:5A
              inet addr:192.168.1.112  Bcast:192.168.1.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:646145 errors:0 dropped:132 overruns:0 frame:0
              TX packets:550661 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:787982745 (751.4 MiB)  TX bytes:726794679 (693.1 MiB)

  9. #29
    Senior Member paul-'s Avatar
    Join Date
    Jan 2013
    Posts
    3,254
    So it seems to handle being flooded better than before. I'll remove the rate limiter from the UI.
    piCorePlayer a small player for the Raspberry Pi in RAM.
    Homepage: https://www.picoreplayer.org

    Please donate if you like the piCorePlayer

  10. #30
    Senior Member mr-b's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    429
    Great - tx.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •