Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #181131 > unrolled thread

[A bit OT] Diagnosing home network

Back to article view | Back to linux.debian.user

Contents

  [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-05-20 07:50 +0200
    Re: [A bit OT] Diagnosing home network Nemeth Gyorgy <friczy@freemail.hu> - 2017-05-20 09:30 +0200
      Re: [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-05-26 10:10 +0200
    Re: [A bit OT] Diagnosing home network rhkramer@gmail.com - 2017-05-20 12:20 +0200
      Re: [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-05-26 10:20 +0200
    Re: [A bit OT] Diagnosing home network Gene Heskett <gheskett@shentel.net> - 2017-05-20 15:40 +0200
      Re: [A bit OT] Diagnosing home network Catherine Gramze <rhiamom@mac.com> - 2017-05-20 17:10 +0200
        Re: [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-05-26 10:20 +0200
      Re: [A bit OT] Diagnosing home network rhkramer@gmail.com - 2017-05-21 19:00 +0200
        Re: [A bit OT] Diagnosing home network Gene Heskett <gheskett@shentel.net> - 2017-05-21 21:20 +0200
        Re: [A bit OT] Diagnosing home network Dan Purgert <dan@djph.net> - 2017-05-22 14:50 +0200
          Re: [A bit OT] Diagnosing home network Gene Heskett <gheskett@shentel.net> - 2017-05-22 17:00 +0200
            Re: [A bit OT] Diagnosing home network Kent West <westk@acu.edu> - 2017-05-22 17:20 +0200
          Re: [A bit OT] Diagnosing home network rhkramer@gmail.com - 2017-05-23 17:30 +0200
            Re: [A bit OT] Diagnosing home network Dan Purgert <dan@djph.net> - 2017-05-24 00:50 +0200
              Re: [A bit OT] Diagnosing home network Brian <ad44@cityscape.co.uk> - 2017-05-24 20:50 +0200
      Re: [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-05-26 10:20 +0200
        Re: [A bit OT] Diagnosing home network Gene Heskett <gheskett@shentel.net> - 2017-05-26 11:00 +0200
        Re: [A bit OT] Diagnosing home network Curt <curty@free.fr> - 2017-05-27 19:10 +0200
          Re: [A bit OT] Diagnosing home network Dan Purgert <dan@djph.net> - 2017-06-01 13:00 +0200
            Re: [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-06-01 13:30 +0200
              Re: [A bit OT] Diagnosing home network メット <mett@pmars.jp> - 2017-06-01 15:10 +0200
              Re: [A bit OT] Diagnosing home network Dan Purgert <dan@djph.net> - 2017-06-02 12:00 +0200
          Re: [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-06-01 13:10 +0200
    Re: [A bit OT] Diagnosing home network Celejar <celejar@gmail.com> - 2017-05-21 05:50 +0200
    Re: [A bit OT] Diagnosing home network David Christensen <dpchrist@holgerdanske.com> - 2017-05-21 06:10 +0200
    Re: [A bit OT] Diagnosing home network Dan Purgert <dan@djph.net> - 2017-05-21 16:40 +0200
      Re: [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-05-24 01:40 +0200
      Re: [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-05-26 10:40 +0200
        Re: [A bit OT] Diagnosing home network Dan Purgert <dan@djph.net> - 2017-05-26 12:30 +0200
          Re: [A bit OT] Diagnosing home network Mark Fletcher <mark27q1@gmail.com> - 2017-05-27 07:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#181641

On Thu, Jun 01, 2017 at 10:39:07AM -0000, Dan Purgert wrote:
> Curt wrote:
> > On 2017-05-26, Mark Fletcher <mark27q1@gmail.com> wrote:
> >>> 
> >> It seems like you read my original problem as slowness accessing the 
> >> internet. That isn't the problem, I'm concerned about intra-LAN speeds. 
> >> Haven't even got the length of worrying about internet speeds yet, since 
> >> there are so many variables that can impact that, I have to be sure my 
> >> end is in tip-top shape before I start poking at that.
> >
> > Intra-LAN speeds; I thought you were speaking of transferring a movie
> > file(?) between two computers on your LAN [...]
> 
> Think he goofed the word, but intranet ("LAN") speeds would affect
> transferring a movie.
> 

No "goof"ing involved, thank you very much -- at least not at this end. 
Intra-LAN means exactly what it says -- inside the LAN. "Inter" means 
"between" -- "intra" means "inside". You seem like a native speaker of 
English, I would have expected you to know that. Apologies if I am 
wrong.

The original reference was in reply to a reply to my original post, in 
which the replier explained how their inTER-LAN, that is from one 
network to another (local LAN to internet, in this case) connection was 
set up -- indicating the poster of that reply had not understood what I 
was trying to do.

> > [...] which couldn't proceed any faster than the receiving end could
> > write that file to disk? I mean, would that not be a limiting factor,
> > even with a quantum link?
> 
> I/O speeds of the drives are definitely a factor -- but pretty much
> anything relatively decent (i.e. not those godawful 5400 RPM laptop
> drives) can read fast enough to saturate a wifi link.  On the "writing"
> side, it's buffered to RAM first, so that'll help (even with a godawful
> slow 5400 RPM laptop drive).
> 
> SSD's shouldn't have much trouble (though, does kind of depend on the
> SATA bus).
> 

Receiver is a high-end laptop hard disk. Based on regular usage of the 
laptop I am extremely confident it is fast enough to not be a factor.  
The overall machine is pretty zippy, even hobbled as it is by Windows 
8.1. The sending end is an SSD mounted on a machine running Jessie. 
Again intra-machine (that word again!) suggest the machine itself is 
healthy and performant.

Next steps on this are for me to follow the advice I've received here 
and try iperf, which I will hopefully have time to do this weekend. I 
see there is a Windows version and that the Linux version is part of 
Jessie. I don't think I am going to have a lot of luck with running on 
my AP as it is not, to my knowledge, running an OS that will let me run 
arbitrary software (and I think I'd sort of be uncomfortable if it were) 
but at least I can put iperf on the two endpoint machines, and on two 
wired LAN machines, and compare. I will post back here if I find 
something interesting.

Mark

[toc] | [prev] | [next] | [standalone]

#181644

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 2017年6月1日 20:21:51 JST, Mark Fletcher <mark27q1@gmail.com> wrote:
>On Thu, Jun 01, 2017 at 10:39:07AM -0000, Dan Purgert wrote:
>> Curt wrote:
>> > On 2017-05-26, Mark Fletcher <mark27q1@gmail.com> wrote:
>> >>>
>> >> It seems like you read my original problem as slowness accessing
>the
>> >> internet. That isn't the problem, I'm concerned about intra-LAN
>speeds.
>> >> Haven't even got the length of worrying about internet speeds yet,
>since
>> >> there are so many variables that can impact that, I have to be
>sure my
>> >> end is in tip-top shape before I start poking at that.
>> >
>> > Intra-LAN speeds; I thought you were speaking of transferring a
>movie
>> > file(?) between two computers on your LAN [...]
>>
>> Think he goofed the word, but intranet ("LAN") speeds would affect
>> transferring a movie.
>>
>
>No "goof"ing involved, thank you very much -- at least not at this end.
>
>Intra-LAN means exactly what it says -- inside the LAN. "Inter" means
>"between" -- "intra" means "inside". You seem like a native speaker of
>English, I would have expected you to know that. Apologies if I am
>wrong.
>
>The original reference was in reply to a reply to my original post, in
>which the replier explained how their inTER-LAN, that is from one
>network to another (local LAN to internet, in this case) connection was
>
>set up -- indicating the poster of that reply had not understood what I
>
>was trying to do.
>
>> > [...] which couldn't proceed any faster than the receiving end
>could
>> > write that file to disk? I mean, would that not be a limiting
>factor,
>> > even with a quantum link?
>>
>> I/O speeds of the drives are definitely a factor -- but pretty much
>> anything relatively decent (i.e. not those godawful 5400 RPM laptop
>> drives) can read fast enough to saturate a wifi link.  On the
>"writing"
>> side, it's buffered to RAM first, so that'll help (even with a
>godawful
>> slow 5400 RPM laptop drive).
>>
>> SSD's shouldn't have much trouble (though, does kind of depend on the
>> SATA bus).
>>
>
>Receiver is a high-end laptop hard disk. Based on regular usage of the
>laptop I am extremely confident it is fast enough to not be a factor.
>The overall machine is pretty zippy, even hobbled as it is by Windows
>8.1. The sending end is an SSD mounted on a machine running Jessie.
>Again intra-machine (that word again!) suggest the machine itself is
>healthy and performant.
>
>Next steps on this are for me to follow the advice I've received here
>and try iperf, which I will hopefully have time to do this weekend. I
>see there is a Windows version and that the Linux version is part of
>Jessie. I don't think I am going to have a lot of luck with running on
>my AP as it is not, to my knowledge, running an OS that will let me run
>
>arbitrary software (and I think I'd sort of be uncomfortable if it
>were)
>but at least I can put iperf on the two endpoint machines, and on two
>wired LAN machines, and compare. I will post back here if I find
>something interesting.
>
>Mark

Try the 2 pc back2back first
and u ll huv an idea of the max speed u can get
HTH
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQE9BAEBCgAnBQJZMA89IBxNZXR0IEhlbF9LZWl0YWkgPG1ldHRAcG1hcnMuanA+
AAoJEPao4OPC92Nku1MH+wcTlWXEOLmTZkYqNvzSW/NF9GulSNl4uqOShpALkg60
sOutbUIbFVHfZklZc7stYw24MvfP2Y7p1wrJ8TDSiYBjctTFq4O+eEFfBuaiUdrA
jMm2HiYW2JNLZssfhBM7SAySdHMuEvPWvsrR/frJO8/sN1ha678JJhLYJawsgh/x
j5K8Xuv20WZN5SMKfMJs697ivMDrjmEsLWJVH3R+GB81gSYW2Im1HbV/Jmrtwotp
vrsQvvnZ1wFmlp5dEE6j4ZWXue/v5a1Tlzweq5ctIuO1MxLKWL/MVFEyUlC2jo6/
qzwCcKGqt3QrH5sc1xmhs5v8gFYxs/xdabapRuPOFxg=
=i1am
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#181692

Mark Fletcher wrote:
> On Thu, Jun 01, 2017 at 10:39:07AM -0000, Dan Purgert wrote:
>> Curt wrote:
>> > On 2017-05-26, Mark Fletcher <mark27q1@gmail.com> wrote:
>> >>> 
>> >> It seems like you read my original problem as slowness accessing the 
>> >> internet. That isn't the problem, I'm concerned about intra-LAN speeds. 
>> >> Haven't even got the length of worrying about internet speeds yet, since 
>> >> there are so many variables that can impact that, I have to be sure my 
>> >> end is in tip-top shape before I start poking at that.
>> >
>> > Intra-LAN speeds; I thought you were speaking of transferring a movie
>> > file(?) between two computers on your LAN [...]
>> 
>> Think he goofed the word, but intranet ("LAN") speeds would affect
>> transferring a movie.
>> 
>
> No "goof"ing involved, thank you very much -- at least not at this end. 
> Intra-LAN means exactly what it says -- inside the LAN. "Inter" means 
> "between" -- "intra" means "inside". You seem like a native speaker of 
> English, I would have expected you to know that. Apologies if I am 
> wrong.

The reason I said you "goofed" is that there is no word "intra-LAN" used
in networking.  The closest (common) word would be "intranet", meaning
precisely what you wanted to convey with your word choice.

>
>> > [...] which couldn't proceed any faster than the receiving end could
>> > write that file to disk? I mean, would that not be a limiting factor,
>> > even with a quantum link?
>> 
>> I/O speeds of the drives are definitely a factor -- but pretty much
>> anything relatively decent (i.e. not those godawful 5400 RPM laptop
>> drives) can read fast enough to saturate a wifi link.  On the "writing"
>> side, it's buffered to RAM first, so that'll help (even with a godawful
>> slow 5400 RPM laptop drive).
>> 
>> SSD's shouldn't have much trouble (though, does kind of depend on the
>> SATA bus).
>> 
>
> Receiver is a high-end laptop hard disk. Based on regular usage of the 
> laptop I am extremely confident it is fast enough to not be a factor.  

Yeah, my comment was more directed at Curt, to explain that while disk
I/O "may" come into play, it really will only do so if the drive's
sustainable speeds are significantly lower than that of the network
link.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#181638

On Sat, May 27, 2017 at 05:08:16PM +0000, Curt wrote:
> On 2017-05-26, Mark Fletcher <mark27q1@gmail.com> wrote:
> >> 
> > It seems like you read my original problem as slowness accessing the 
> > internet. That isn't the problem, I'm concerned about intra-LAN speeds. 
> > Haven't even got the length of worrying about internet speeds yet, since 
> > there are so many variables that can impact that, I have to be sure my 
> > end is in tip-top shape before I start poking at that.
> 
> Intra-LAN speeds; I thought you were speaking of transferring a movie file(?)
> between two computers on your LAN, which couldn't proceed any faster than the
> receiving end could write that file to disk? I mean, would that not be a
> limiting factor, even with a quantum link?
> 
> 
Yes. And writing to a disk (a laptop hard disk in this case) is going to 
be a lot faster than what I can transfer over the LAN, I would have 
thought. Not sure what your point is here, don't think I've got it.

Mark

[toc] | [prev] | [next] | [standalone]

#181167

On Sat, 20 May 2017 14:41:20 +0900
Mark Fletcher <mark27q1@gmail.com> wrote:

> Hello!
> 
> I have some doubts about the throughput of my home network and I'm 
> hoping for some advice on tools that might help me diagnose it.

...

> I'd like to be able to diagnose what's going on here, why the transfer 
> was so slow. Any recommendations for tools I should research? I am very 
> willing to read man pages etc, but am a bit lost where to start. Google 
> gave me a lot of Windows-based stuff which I could look into but I would 
> prefer to use Linux-based tools if possible.
> 
> Pointers to tools I should research -- and even better, links to good 
> tutorials on those tools if you know any -- would be much appreciated.

I'm no expert, but here are a few common sense suggestions, some
learned in the course of doing similar testing on my home network:

1) As another post mentioned, iperf is the basic tool for testing
throughput between two network endpoints. [There are various
versions; I use the basic 'iperf'. Just make sure you're running the
same version all over.] You need to run it on both endpoints, however,
so this won't work where you can't run arbitrary stuff on one. On my
router, I run OpenWrt / Lede, so I can run iperf there, but you may not
be able to. If iperf isn't an option, a manual test is the most basic
option: download a large file using the most basic protocol you can (to
minimize overhead), e.g., http via wget, ssh / scp, etc., and divide
bytes [and see #5 below!] transferred by time.

2) Always, especially with wireless, run tests in both directions. I've
seen dramatic differences over my wireless links, presumably due to
variations in antenna sensitivity and transmitting power.

3) It's always good to test individual network legs, to get more
fundamental measurements of the underlying bandwidth across those
different legs. So ideally, you'd want to measure throughput between
the devices connected to the switch / access point and the switch /
access point itself. Afterward, you can take measurements between
different endpoints that connect across the switch / access point, or
between your endpoints and internet sites (such as speedtest sites).

4) For internet speed tests, there are various options. One popular one
is speedtest.net, which even has a command line client in Debian
(speedtest-cli).

5) Very important: always remember that communication speeds are
usually specified in technical contexts in [G/M/K]*bits* per second,
but in non-technical contexts are often given in [G/M/K]*bytes* per
second. Especially when you're dealing with file transfers, and want to
figure out how long they will / should take, you'll be doing byte
per second calculations. Make sure you keep track of which unit you're
using, and convert accordingly.

Celejar

[toc] | [prev] | [next] | [standalone]

#181168

On 05/19/2017 10:41 PM, Mark Fletcher wrote:
> Hello!

Hi!  :-)


> I have some doubts about the throughput of my home network and I'm
> hoping for some advice on tools that might help me diagnose it.
>
> My home network consists of 2 Debian machines, one Jessie and one
> Stretch, an LFS mini-ITX machine acting as my firewall, another LFS
> laptop that is connected only occasionally, a Windows 8.1 laptop, 3
> iPhones of varying ages, 2 iPads, 1 Android tablet device, a couple of
> other proprietary tablets and a Buffalo Linkstation that provides most
> of the connectivity.
>
> The internet access is via Cable. I run an ethernet cable from the cable
> modem to the firewall machine, then from the firewall machine to the
> Linkstation's WAN port. The firewall machine's WiFi interface is
> disabled (I didn't include its driver when I built the kernel for that
> machine). The Jessie box, a phone-to-ethernet device and a NAS are
> plugged into the Linkstation wired LAN ports. Everything else connects
> to the Linkstation WiFi.

Which model Buffalo LinkStation do you have?  I can't find one with more 
than one LAN port:

http://www.buffalo-technology.com/en/products/storage-devices/consumer-nas/linkstationtm/


The terms 'wifi' and 'wan' do not appear on the Wikipedia page:

https://en.wikipedia.org/wiki/Buffalo_network-attached_storage_series


> The LinkStation offers 2.4GHz and 5GHz
> connections, the 2.4GHz is b/g and the 5GHz is ac I believe. Those
> devices that can use the 5GHz connection, are, the rest are using the
> 2.4GHz.
>
> I have my doubts about cross-LAN throughput. For example, as I write I
> am using WinSCP on the Windows 8.1 laptop to copy a movie file from my
> Jessie box to the laptop. (The movie concerned is not copyright before
> anyone asks). The Jessie box is connected to the LinkStation by wired
> ethernet, and the Windows 8.1 laptop by WiFi. I am getting a transfer
> rate consistently across the life of the connection of 880KB/s. I'd
> expect it to be a lot faster than that. I checked the WinSCP software is
> capable of limiting the connection speed, but is set not to.
>
> The laptop is situated here on my desktop, less than 2 feet from the
> LinkStation (albet with a computer monitor between them).

Radio devices placed too close can create problems.  I put my WiFi 
access points/ routers high on a wall near the center of my house.  All 
my WiFi devices are 3+ meters away.


> Neither laptop
> nor Jessie box were doing anything else at the time -- the load on the
> Jessie box was essentially zero before the transfer started, rose to 1
> while the transfer was going on, then fell back to basically zero when
> it finished (monitored using xload).
>
> I'd like to be able to diagnose what's going on here, why the transfer
> was so slow. Any recommendations for tools I should research? I am very
> willing to read man pages etc, but am a bit lost where to start. Google
> gave me a lot of Windows-based stuff which I could look into but I would
> prefer to use Linux-based tools if possible.
>
> Pointers to tools I should research -- and even better, links to good
> tutorials on those tools if you know any -- would be much appreciated.

I'd start with ifconfig (Debian), ipconfig (Windows), whatever network 
interface management graphical user intefaces (GUI) they provide, and 
whatever web user interface (WUI) your wired/WiFi router provides.  Try 
to find out the speed, duplex, etc., of the links between the router and 
Jesse and the router and Windows.  Look for indicators of link layer 
errors.  On Jesse, look at the files in /var/log for clues.  On Windows, 
figure out where error messages go and take a look (Event Viewer?).


A bad Ethernet cable could degrade the connection to 10 Mbps and/or 
half-duplex.


As you're looking at the GUI/WUI's, copy all of the settings into plain 
text files, one per interface (yes, this will take a fair amount of typing).


Your router WUI should have a mechanism for backing up and restoring all 
of the settings to/from a file.  Back up the settings.


Pick a benchmark and run it as a baseline.  Copying a big file via 
WinSCP from Jesse to Windows and using a stopwatch is a valid benchmark. 
  Type this information into the text file (cut and paste, if possible). 
  Also consider the reverse direction.  Also consider copying Jesse to 
LinkStation and reverse, and Windows to LinkStation and reverse.


Then, start making changes.  Make one change, document it, power cycle 
the entire network, run all benchmarks, and document them.


Look for settings that can be automatic or manual, but are set to 
manual.  Change them to automatic.


When my laptop is at my SOHO work area, I use it's LAN connection -- 
with the equipment I have, wired is always faster that WiFi.


David

[toc] | [prev] | [next] | [standalone]

#181190

Mark Fletcher wrote:
>
> My home network consists of 2 Debian machines, one Jessie and one 
> Stretch, an LFS mini-ITX machine acting as my firewall, another LFS 
> laptop that is connected only occasionally, a Windows 8.1 laptop, 3 
> iPhones of varying ages, 2 iPads, 1 Android tablet device, a couple of 
> other proprietary tablets and a Buffalo Linkstation that provides most 
> of the connectivity.

Quick google doesn't show any "Linkstation" devices with more than one
ethernet port (much less wifi).  Do you perhaps mean an "Airstation"?
Could you provide the model number, so we can look it up?

> [...]
> I have my doubts about cross-LAN throughput. For example, as I write I 
> am using WinSCP on the Windows 8.1 laptop to copy a movie file from my 
> Jessie box to the laptop. (The movie concerned is not copyright before 
> anyone asks). The Jessie box is connected to the LinkStation by wired 
> ethernet, and the Windows 8.1 laptop by WiFi. I am getting a transfer 
> rate consistently across the life of the connection of 880KB/s. I'd 
> expect it to be a lot faster than that. I checked the WinSCP software is 
> capable of limiting the connection speed, but is set not to.


880KB (we'll call it 1 MB) / kilobytes per second is about 8 megabits
per second (1 byte = 8 bits).  8 mbit is a touch low (but in the
"range") of what you can expect from 802.11g.  802.11n may also fall
this low, but generally only when there's interference / poor signal.

A VERY rough rule of thumb is that on a perfectly clear channel, you can
expect your throughput to be approximately 1/3 to 1/2 of the "on the
box" speed (so 802.11g - 54mbit/sec yields roughly 18-24 mbit) for ONE
device connected to the AP.

>From there, you have to divide up the available throughput by number of
clients (i.e. a given wifi client's speed is 1/n, assuming that all
clients are using the same technology).  So if your wifi was *perfect*
for 802.11g, and one client got 24 mbit -- 2 clients would average 12
mbit each, 3 would average 8, and so on.  

In addition to "your clients", you have to contend with neighbors on the
same channels (who add to the 1/n throughput troubles).  5 GHz helps
here, as it's less likely that the clients in your home will see the 5
GHz signal from your neighbors, even if you are on the same channel.

> [...]
>
> I'd like to be able to diagnose what's going on here, why the transfer 
> was so slow. Any recommendations for tools I should research? I am very 
> willing to read man pages etc, but am a bit lost where to start. Google 
> gave me a lot of Windows-based stuff which I could look into but I would 
> prefer to use Linux-based tools if possible.
>
> Pointers to tools I should research -- and even better, links to good 
> tutorials on those tools if you know any -- would be much appreciated.

iperf would be a solid start.  Run it from one machine to another (e.g.
the wireless laptop to a wired desktop).  Don't try running it on the
router / access point / switch (if you have any of those), as iperf can
be resource intensive, so you "lose" a lot of speed due to their
processor not being able to keep up with the packet generation.

Also check your wifi channel usage -- 2.4 GHz should be on channel 1, 6,
or 11 (if you're somewhere where 13 is allowed, you could try that too).
If you use any other channel (2-5 or 7-10), you're going to be getting a
lot of interference (and throughput losses) from your neighbors.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#181300

On Sun, May 21, 2017 at 02:18:06PM -0000, Dan Purgert wrote:
> Mark Fletcher wrote:
> >
> > My home network consists of 2 Debian machines, one Jessie and one 
> > Stretch, an LFS mini-ITX machine acting as my firewall, another LFS 
> > laptop that is connected only occasionally, a Windows 8.1 laptop, 3 
> > iPhones of varying ages, 2 iPads, 1 Android tablet device, a couple of 
> > other proprietary tablets and a Buffalo Linkstation that provides most 
> > of the connectivity.
> 
> Quick google doesn't show any "Linkstation" devices with more than one
> ethernet port (much less wifi).  Do you perhaps mean an "Airstation"?
> Could you provide the model number, so we can look it up?

Thanks everyone for your suggestions. I"m now travelling for business, 
hence the delay in replying. I will check on my return at the end of the 
week and reply.


Mark
> 
> > [...]
> > I have my doubts about cross-LAN throughput. For example, as I write I 
> > am using WinSCP on the Windows 8.1 laptop to copy a movie file from my 
> > Jessie box to the laptop. (The movie concerned is not copyright before 
> > anyone asks). The Jessie box is connected to the LinkStation by wired 
> > ethernet, and the Windows 8.1 laptop by WiFi. I am getting a transfer 
> > rate consistently across the life of the connection of 880KB/s. I'd 
> > expect it to be a lot faster than that. I checked the WinSCP software is 
> > capable of limiting the connection speed, but is set not to.
> 
> 
> 880KB (we'll call it 1 MB) / kilobytes per second is about 8 megabits
> per second (1 byte = 8 bits).  8 mbit is a touch low (but in the
> "range") of what you can expect from 802.11g.  802.11n may also fall
> this low, but generally only when there's interference / poor signal.
> 
> A VERY rough rule of thumb is that on a perfectly clear channel, you can
> expect your throughput to be approximately 1/3 to 1/2 of the "on the
> box" speed (so 802.11g - 54mbit/sec yields roughly 18-24 mbit) for ONE
> device connected to the AP.
> 
> >From there, you have to divide up the available throughput by number of
> clients (i.e. a given wifi client's speed is 1/n, assuming that all
> clients are using the same technology).  So if your wifi was *perfect*
> for 802.11g, and one client got 24 mbit -- 2 clients would average 12
> mbit each, 3 would average 8, and so on.  
> 
> In addition to "your clients", you have to contend with neighbors on the
> same channels (who add to the 1/n throughput troubles).  5 GHz helps
> here, as it's less likely that the clients in your home will see the 5
> GHz signal from your neighbors, even if you are on the same channel.
> 
> > [...]
> >
> > I'd like to be able to diagnose what's going on here, why the transfer 
> > was so slow. Any recommendations for tools I should research? I am very 
> > willing to read man pages etc, but am a bit lost where to start. Google 
> > gave me a lot of Windows-based stuff which I could look into but I would 
> > prefer to use Linux-based tools if possible.
> >
> > Pointers to tools I should research -- and even better, links to good 
> > tutorials on those tools if you know any -- would be much appreciated.
> 
> iperf would be a solid start.  Run it from one machine to another (e.g.
> the wireless laptop to a wired desktop).  Don't try running it on the
> router / access point / switch (if you have any of those), as iperf can
> be resource intensive, so you "lose" a lot of speed due to their
> processor not being able to keep up with the packet generation.
> 
> Also check your wifi channel usage -- 2.4 GHz should be on channel 1, 6,
> or 11 (if you're somewhere where 13 is allowed, you could try that too).
> If you use any other channel (2-5 or 7-10), you're going to be getting a
> lot of interference (and throughput losses) from your neighbors.
> 
> 
> -- 
> |_|O|_| Registered Linux user #585947
> |_|_|O| Github: https://github.com/dpurgert
> |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281
> 

[toc] | [prev] | [next] | [standalone]

#181398

On Sun, May 21, 2017 at 02:18:06PM -0000, Dan Purgert wrote:
> Mark Fletcher wrote:
> >
> > My home network consists of 2 Debian machines, one Jessie and one 
> > Stretch, an LFS mini-ITX machine acting as my firewall, another LFS 
> > laptop that is connected only occasionally, a Windows 8.1 laptop, 3 
> > iPhones of varying ages, 2 iPads, 1 Android tablet device, a couple of 
> > other proprietary tablets and a Buffalo Linkstation that provides most 
> > of the connectivity.
> 
> Quick google doesn't show any "Linkstation" devices with more than one
> ethernet port (much less wifi).  Do you perhaps mean an "Airstation"?
> Could you provide the model number, so we can look it up?

Oops. Quite right. It is an AirStation. Specifically, a WZR-1750-DHP2. 
When I google it everything I find is in Japanese, possibly this model 
was only ever sold in Japan.

> 
> > [...]
> > I have my doubts about cross-LAN throughput. For example, as I write I 
> > am using WinSCP on the Windows 8.1 laptop to copy a movie file from my 
> > Jessie box to the laptop. (The movie concerned is not copyright before 
> > anyone asks). The Jessie box is connected to the LinkStation by wired 
> > ethernet, and the Windows 8.1 laptop by WiFi. I am getting a transfer 
> > rate consistently across the life of the connection of 880KB/s. I'd 
> > expect it to be a lot faster than that. I checked the WinSCP software is 
> > capable of limiting the connection speed, but is set not to.
> 
> 
> 880KB (we'll call it 1 MB) / kilobytes per second is about 8 megabits
> per second (1 byte = 8 bits).  8 mbit is a touch low (but in the
> "range") of what you can expect from 802.11g.  802.11n may also fall
> this low, but generally only when there's interference / poor signal.
> 
> A VERY rough rule of thumb is that on a perfectly clear channel, you can
> expect your throughput to be approximately 1/3 to 1/2 of the "on the
> box" speed (so 802.11g - 54mbit/sec yields roughly 18-24 mbit) for ONE
> device connected to the AP.
> 
> >From there, you have to divide up the available throughput by number of
> clients (i.e. a given wifi client's speed is 1/n, assuming that all
> clients are using the same technology).  So if your wifi was *perfect*
> for 802.11g, and one client got 24 mbit -- 2 clients would average 12
> mbit each, 3 would average 8, and so on.  
> 

If they were all talking at the same time, right? Just sitting there 
doing nothing shouldn't use up a _lot_ of bandwidth on ethernet, 
although doubtless keepalives and so on will use some.

> In addition to "your clients", you have to contend with neighbors on the
> same channels (who add to the 1/n throughput troubles).  5 GHz helps
> here, as it's less likely that the clients in your home will see the 5
> GHz signal from your neighbors, even if you are on the same channel.
> 
> > [...]
> >
> > I'd like to be able to diagnose what's going on here, why the transfer 
> > was so slow. Any recommendations for tools I should research? I am very 
> > willing to read man pages etc, but am a bit lost where to start. Google 
> > gave me a lot of Windows-based stuff which I could look into but I would 
> > prefer to use Linux-based tools if possible.
> >
> > Pointers to tools I should research -- and even better, links to good 
> > tutorials on those tools if you know any -- would be much appreciated.
> 
> iperf would be a solid start.  Run it from one machine to another (e.g.
> the wireless laptop to a wired desktop).  Don't try running it on the
> router / access point / switch (if you have any of those), as iperf can
> be resource intensive, so you "lose" a lot of speed due to their
> processor not being able to keep up with the packet generation.
> 
> Also check your wifi channel usage -- 2.4 GHz should be on channel 1, 6,
> or 11 (if you're somewhere where 13 is allowed, you could try that too).
> If you use any other channel (2-5 or 7-10), you're going to be getting a
> lot of interference (and throughput losses) from your neighbors.
> 
> 
Channel selection is automatic -- shouldn't it pick the clearest one? 
Also I am curious as to why selecting 1, 6, 11 or 13 if available is 
better and less likely to result in interference?

[toc] | [prev] | [next] | [standalone]

#181403

Mark Fletcher wrote:
> On Sun, May 21, 2017 at 02:18:06PM -0000, Dan Purgert wrote:
>> Mark Fletcher wrote:
>> >
>> > My home network consists of 2 Debian machines, one Jessie and one 
>> > Stretch, an LFS mini-ITX machine acting as my firewall, another LFS 
>> > laptop that is connected only occasionally, a Windows 8.1 laptop, 3 
>> > iPhones of varying ages, 2 iPads, 1 Android tablet device, a couple of 
>> > other proprietary tablets and a Buffalo Linkstation that provides most 
>> > of the connectivity.
>> 
>> Quick google doesn't show any "Linkstation" devices with more than one
>> ethernet port (much less wifi).  Do you perhaps mean an "Airstation"?
>> Could you provide the model number, so we can look it up?
>
> Oops. Quite right. It is an AirStation. Specifically, a WZR-1750-DHP2. 
> When I google it everything I find is in Japanese, possibly this model 
> was only ever sold in Japan.

Happens :).. "Japanese only" is gonna make it hard for me to read the
specs though.

>
>> 
>> [...]
>> From there, you have to divide up the available throughput by number of
>> clients (i.e. a given wifi client's speed is 1/n, assuming that all
>> clients are using the same technology).  So if your wifi was *perfect*
>> for 802.11g, and one client got 24 mbit -- 2 clients would average 12
>> mbit each, 3 would average 8, and so on.  
>> 
>
> If they were all talking at the same time, right? Just sitting there 
> doing nothing shouldn't use up a _lot_ of bandwidth on ethernet, 
> although doubtless keepalives and so on will use some.

More or less -- idle clients (on your WLAN) don't take up much
bandwidth.  It's more the next bit (neighbors on the same channel)
that's more likely to cause you trouble.

>
>> In addition to "your clients", you have to contend with neighbors on the
>> same channels (who add to the 1/n throughput troubles).  5 GHz helps
>> here, as it's less likely that the clients in your home will see the 5
>> GHz signal from your neighbors, even if you are on the same channel.
>> 
>> > [...]
>> 
>> Also check your wifi channel usage -- 2.4 GHz should be on channel 1, 6,
>> or 11 (if you're somewhere where 13 is allowed, you could try that too).
>> If you use any other channel (2-5 or 7-10), you're going to be getting a
>> lot of interference (and throughput losses) from your neighbors.
>> 
>> 
> Channel selection is automatic -- shouldn't it pick the clearest one? 
> Also I am curious as to why selecting 1, 6, 11 or 13 if available is 
> better and less likely to result in interference?

"automatic" is a nice way of saying "braindead" in many instances.
Nearly all gear (until you're spending $1500+ for a single AP) is only
"auto" when it boots up ... and 9 times out of 10, it'll pull some
stupid channel like 3.

The reason for channels 1, 6, or 11 is that 
 (a) they're universal channels globally
 (b) they're the only three (2.4 GHz) channels that don't overlap

For the "standard" channels (1-11), they are 20 MHz wide, and center
frequencies are spaced 5 MHz apart. This means that channels 1 and 2
(for example) overlap their spectrum use about 3/4.  In turn, this
raises the noise floor on both WLANs, leading to garbled packets /
re-transmissions / other slowdowns -- all of which get mitigated by
using channels 1,6,11 simply because they don't overlap.

On the other side - with "everyone" using 1,6,11 - if two APs (or client
devices) on the same channel are able to "hear" each other, they'll both
employ their collision avoidance routines to share the channel - even
when they're on different WLANs.  It's just simple checks along the
lines of 

  1. Is anyone transmitting right now?
    * If yes, wait til they're done, plus random milliseconds, then
      goto2
    * If no, wait random milliseconds, then goto2
  2. Start transmitting 


It's not perfect, and sometimes you get "hidden node" issues (where say
your laptop and mine can't hear each other transmit, but our respective
APs can - they'll then send us the "shutup, someone else is transmitting"
signal), but instead of both WLANs trying to shout over each other and
simply generate noise - which near on always slows everything down -
they share.  Sure, sharing the channel means some degree of slowdown,
but it's generally not nearly as pronounced as those caused by
interference.

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#181479

On Fri, May 26, 2017 at 10:09:08AM -0000, Dan Purgert wrote:
> Mark Fletcher wrote:
> > On Sun, May 21, 2017 at 02:18:06PM -0000, Dan Purgert wrote:
> >> Mark Fletcher wrote:
> >> >
> >> 
> > Channel selection is automatic -- shouldn't it pick the clearest one? 
> > Also I am curious as to why selecting 1, 6, 11 or 13 if available is 
> > better and less likely to result in interference?
> 
> "automatic" is a nice way of saying "braindead" in many instances.
> Nearly all gear (until you're spending $1500+ for a single AP) is only
> "auto" when it boots up ... and 9 times out of 10, it'll pull some
> stupid channel like 3.
> 
> The reason for channels 1, 6, or 11 is that 
>  (a) they're universal channels globally
>  (b) they're the only three (2.4 GHz) channels that don't overlap
> 
> For the "standard" channels (1-11), they are 20 MHz wide, and center
> frequencies are spaced 5 MHz apart. This means that channels 1 and 2
> (for example) overlap their spectrum use about 3/4.  In turn, this
> raises the noise floor on both WLANs, leading to garbled packets /
> re-transmissions / other slowdowns -- all of which get mitigated by
> using channels 1,6,11 simply because they don't overlap.
> 
> On the other side - with "everyone" using 1,6,11 - if two APs (or client
> devices) on the same channel are able to "hear" each other, they'll both
> employ their collision avoidance routines to share the channel - even
> when they're on different WLANs.  It's just simple checks along the
> lines of 
> 
>   1. Is anyone transmitting right now?
>     * If yes, wait til they're done, plus random milliseconds, then
>       goto2
>     * If no, wait random milliseconds, then goto2
>   2. Start transmitting 
> 
> 
> It's not perfect, and sometimes you get "hidden node" issues (where say
> your laptop and mine can't hear each other transmit, but our respective
> APs can - they'll then send us the "shutup, someone else is transmitting"
> signal), but instead of both WLANs trying to shout over each other and
> simply generate noise - which near on always slows everything down -
> they share.  Sure, sharing the channel means some degree of slowdown,
> but it's generally not nearly as pronounced as those caused by
> interference.
> 

Fascinating. And makes lots of sense -- thanks! I've entirely left 
channel selection up to the AP so gawd alone knows what channel state I 
am in. I will do battle with the Japanese-language WUI to find out...

Actually maybe I will have more luck interrogating the client side for 
that...

Mark

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web