Re: [A bit OT] Diagnosing home network

[Dan Purgert]

Mark Fletcher wrote:
> On Thu, Jun 01, 2017 at 10:39:07AM -, Dan Purgert wrote:
>> Curt wrote:
>> > On 2017-05-26, Mark Fletcher  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

Re: [A bit OT] Diagnosing home network

[メット]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 2017年6月1日 20:21:51 JST, Mark Fletcher  wrote:
>On Thu, Jun 01, 2017 at 10:39:07AM -, Dan Purgert wrote:
>> Curt wrote:
>> > On 2017-05-26, Mark Fletcher  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-

Re: [A bit OT] Diagnosing home network

[Mark Fletcher]

On Thu, Jun 01, 2017 at 10:39:07AM -, Dan Purgert wrote:
> Curt wrote:
> > On 2017-05-26, Mark Fletcher  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

Re: [A bit OT] Diagnosing home network

[Mark Fletcher]

On Sat, May 27, 2017 at 05:08:16PM +, Curt wrote:
> On 2017-05-26, Mark Fletcher  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

Re: [A bit OT] Diagnosing home network

[Dan Purgert]

Curt wrote:
> On 2017-05-26, Mark Fletcher  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.

> [...] 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).



>
>
>> Mark
>>
>>
>
>


-- 
|_|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

Re: [A bit OT] Diagnosing home network

[Curt]

On 2017-05-26, Mark Fletcher  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?


> Mark
>
>


-- 
"It might be a vision--of a shell, of a wheelbarrow, of a fairy kingdom on the
far side of the hedge; or it might be the glory of speed; no one knew." --Mrs.
Ramsay, speculating on why her little daughter might be dashing about, in "To
the Lighthouse," by Virginia Woolf.

Re: [A bit OT] Diagnosing home network

[Mark Fletcher]

On Fri, May 26, 2017 at 10:09:08AM -, Dan Purgert wrote:
> Mark Fletcher wrote:
> > On Sun, May 21, 2017 at 02:18:06PM -, 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

Re: [A bit OT] Diagnosing home network

[Dan Purgert]

Mark Fletcher wrote:
> On Sun, May 21, 2017 at 02:18:06PM -, 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

Re: [A bit OT] Diagnosing home network

[Gene Heskett]

On Friday 26 May 2017 04:17:10 Mark Fletcher wrote:

> On Sat, May 20, 2017 at 09:38:21AM -0400, Gene Heskett wrote:
> > On Saturday 20 May 2017 01:41:20 Mark Fletcher wrote:
> >
> > Couple things here. I have no such problems. My routing is from the
> > cable modem, to a buffalo netfinty router running dd-wrt, so I need
> > no firewall. dd-wrt has very sharp teeth so I don't seem to need an
> > additional guard dog. The output of the buffalo hits an 8 port
> > managed switch, and everything else is plugged into that switch.
> > There are 2 more switch/hubs plugged into that switch so that one
> > cable to the garage hitting an 8 port switch in the garage that
> > feeds 3 machines there, and another cable thats been blowing in the
> > wind for about 15 years now, runs from the house to a 12x16 shop
> > building in the upper rear corner of the back yard, where always 2,
> > and occasionally a 3rd machine is plugged into a 4 port hub.  The 2
> > 8 port switches and the hub are gigahertz capable.  Even the
> > machines in the shop building can access the internet at megabyte+ a
> > second speeds.  Amanda hits them all at about 1:30 am, and even
> > then, with that load on this machine slowing it some, I don't notice
> > a huge networking data slowdown.
> >
> > You'll note no mention of wifi here as its turned off unless I have
> > children visiting with their smart phones.  wifi is slower, and
> > subject to being used by the neighbors as I found my net usage after
> > the kids had been in was up about 80 Gb a month later. I don't
> > couple the wifi to my net, only to the internet, but inspecting
> > dd-wrt's list of dhcpd'd net leases disclosed that a neighbor seemed
> > to have discovered it and was helping himself to my bandwidth. So I
> > had to log back into the buffalo and turn the radio off again. As
> > the garage has vinyl siding, I have to do the same thing on a
> > raspberry pi 3b out there, which has an excellent wifi, and I had to
> > shut it off too. The raspian-jessie defaults enable it, and a dhcpd
> > server, so it was handing out addresses and connections on wlan0,
> > using bandwidth I could see.  Ooops.  And I have to do it everytime
> > I build a new sd card for it. dhcpcd killed forever now, or until I
> > change sd cards.
> >
> > I configured for future expansion, whereas your setup sounds like
> > its machine to machine.  So get a router you can reflash, ditch the
> > firewall, and feed the routerr (after setting up NAT in the router
> > to put your local network on a local address in the 192.168.xx.zz
> > block of addresses) and if you must have dhcpcd for your wireless
> > stuff, do it in the router. Everything here is in /etc/hosts,
> > resolv.conf says order host,dns, and dns is pointed at the router,
> > and forwards dns requests to my ISP's dns servers.  And from this
> > end, its all transparent, but the black hats are SOL, blocked at the
> > router. I've one  porthole cut in that, to allow access to my web
> > page in the sig.  Other than that, no one has come thru that setup
> > and gotten into one of my machines in close to 15 years.
>
> 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.
>
> Mark

I see.  That lashup I've described has not exhibited any such speed 
problems. I have a so-called 10 megabit cable pipe that I quite often 
see 1.2 megabyte download speeds on any of the 7 machines currently 
powered up. Intra-net speeds, from machine to machine rather handily 
exceed that, but I do not have any samba shares, nor any flavor of NFS, 
all intranet data movement is by sshfs mounts.  That has the added 
advantage of being encrypted on the cat5 interconnection.

Regardless of the local net speeds, security starts by posting a guard 
dog that never sleeps between you and the internet, in the form of a 
router with enough flash memory that it can be reflashed with dd-wrt, 
and have it setup to NAT the internet address to a local address, which 
gives you, in 254 address blocks, just short of 65535 addresses that are 
not forwarded out of your local network, ever.  That reduces your 
exposure to the script kiddies to about .001% of what it 
would be if connected directly to the  network. dd-wrt has no NSA back 
doors that we've found. The only one who has come thru it in the 1.5 
decades I've been using it, was a friend and co-worker whose help  I 
needed and I gave him the ssh logins to do that.  Yet to me, from here, 
its absolutely transparent.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: [A bit OT] Diagnosing home network

[Mark Fletcher]

On Sun, May 21, 2017 at 02:18:06PM -, 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?

Re: [A bit OT] Diagnosing home network

[Mark Fletcher]

On Sat, May 20, 2017 at 09:49:43AM -0400, Catherine Gramze wrote:
> 
> 
> > On May 20, 2017, at 9:38 AM, Gene Heskett  wrote:
> > 
> >> On Saturday 20 May 2017 01:41:20 Mark Fletcher 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.
> >> 
> >> 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. 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.
> 
> >> .
> >> 
> >> Thanks in advance
> >> 
> >> Mark
> 
> >  Delurking. Just a quick suggestion here. Do you have the proprietary 
> > non-free firmware installed for all your NICs? When they work without the 
> > firmware it is often a much slower connection, like b when the NIC is 
> > capable of n or a/c, but only when using the proprietary firmware. 
> 

Interesting. The Jessie box is using wired LAN via an onboard (ie part 
of the motherboard) ethernet controller (motherboard is an ASUS P6T 
iirc). I wouldn't expect it to need firmware, would I be wrong?

At the laptop end, it's running Windows 8.1 so gawd alone knows what can 
/ should be updated...

Mark

Re: [A bit OT] Diagnosing home network

[Mark Fletcher]

On Sat, May 20, 2017 at 09:38:21AM -0400, Gene Heskett wrote:
> On Saturday 20 May 2017 01:41:20 Mark Fletcher wrote:
> 
> Couple things here. I have no such problems. My routing is from the cable 
> modem, to a buffalo netfinty router running dd-wrt, so I need no 
> firewall. dd-wrt has very sharp teeth so I don't seem to need an 
> additional guard dog. The output of the buffalo hits an 8 port managed 
> switch, and everything else is plugged into that switch. There are 2 
> more switch/hubs plugged into that switch so that one cable to the 
> garage hitting an 8 port switch in the garage that feeds 3 machines 
> there, and another cable thats been blowing in the wind for about 15 
> years now, runs from the house to a 12x16 shop building in the upper 
> rear corner of the back yard, where always 2, and occasionally a 3rd 
> machine is plugged into a 4 port hub.  The 2 8 port switches and the hub 
> are gigahertz capable.  Even the machines in the shop building can 
> access the internet at megabyte+ a second speeds.  Amanda hits them all 
> at about 1:30 am, and even then, with that load on this machine slowing 
> it some, I don't notice a huge networking data slowdown.
> 
> You'll note no mention of wifi here as its turned off unless I have 
> children visiting with their smart phones.  wifi is slower, and subject 
> to being used by the neighbors as I found my net usage after the kids 
> had been in was up about 80 Gb a month later. I don't couple the wifi to 
> my net, only to the internet, but inspecting dd-wrt's list of dhcpd'd 
> net leases disclosed that a neighbor seemed to have discovered it and 
> was helping himself to my bandwidth. So I had to log back into the 
> buffalo and turn the radio off again. As the garage has vinyl siding, I 
> have to do the same thing on a raspberry pi 3b out there, which has an 
> excellent wifi, and I had to shut it off too. The raspian-jessie 
> defaults enable it, and a dhcpd server, so it was handing out addresses 
> and connections on wlan0, using bandwidth I could see.  Ooops.  And I 
> have to do it everytime I build a new sd card for it. dhcpcd killed 
> forever now, or until I change sd cards.
> 
> I configured for future expansion, whereas your setup sounds like its 
> machine to machine.  So get a router you can reflash, ditch the 
> firewall, and feed the routerr (after setting up NAT in the router to 
> put your local network on a local address in the 192.168.xx.zz block of 
> addresses) and if you must have dhcpcd for your wireless stuff, do it in 
> the router. Everything here is in /etc/hosts, resolv.conf says order 
> host,dns, and dns is pointed at the router, and forwards dns requests to 
> my ISP's dns servers.  And from this end, its all transparent, but the 
> black hats are SOL, blocked at the router. I've one  porthole cut in 
> that, to allow access to my web page in the sig.  Other than that, no 
> one has come thru that setup and gotten into one of my machines in close 
> to 15 years.
> 

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.

Mark

Re: [A bit OT] Diagnosing home network

[Mark Fletcher]

On Sat, May 20, 2017 at 06:17:41AM -0400, rhkra...@gmail.com wrote:
> On Saturday, May 20, 2017 01:41:20 AM Mark Fletcher wrote:
> 
> What is the laptop using--802.11a, b, g, n, or ac?

It's a high-end couple-of-years-old Toshiba laptop sold in Japan. It'll 
be either N or AC. I believe the router does not offer anything slower 
on the 5GHz band.

> 
> What is the Jessie system using--802.11a, b, g, n, or ac?

As I stated in my original mail, it's wired, plugged into one of the 
AirStation's LAN ports. (and yes, as someone else pointed out, it is an 
AirStation not a LinkStation -- silly me).

> 
> (I/m not sure how you can determine this--maybe the LInk Station has a 
> "maintainance" screen you can access?)
> 
> (Also, the Linkstation has to act as a repeater between the laptop and Jessie 
> system--I'm not sure how much that might slow the transfer.)
> 

But that's it's entire raison d'etre so I would expect it to be good at it.

> Anyway, note that the theoretical throughput of 802.11b is 11 Mbps--your 880 
> KB/s is reasonably consistent with that.  IIRC, 802.11g can do 54 Mbps, I'm 
> not sure about the others.
> 

HOPEFULLY that is going to turn out to be irrelevant, as I don't think b 
is involved... I don't THINK it is, it SHOULDN'T be... The close match 
between theory and observation is suspicious though...

Mark

Re: [A bit OT] Diagnosing home network

[Mark Fletcher]

On Sat, May 20, 2017 at 09:29:12AM +0200, Nemeth Gyorgy wrote:
> 2017-05-20 07:41 keltezéssel, Mark Fletcher írta:
> > 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.
> >
> For speed measuring I suggest iperf.
> 
 Cool, thanks. I will check that out.

Mark

Re: [A bit OT] Diagnosing home network

[Brian]

On Tue 23 May 2017 at 22:32:52 -, Dan Purgert wrote:

> rhkra...@gmail.com wrote:
> > On Monday, May 22, 2017 08:28:54 AM Dan Purgert wrote:
> >
> >> Probably WPA2-PSK ("Pre Shared Key") -- just means "password auth".
> >> TBH, not having the SSID transmitted is actually LESS secure (overall)
> >> than just having it transmit, due to the fact that your client devices
> >> (phone, laptop, etc) have to broadcast "hey, I'm looking for SSID,
> >> any APs in range have that one?"
> >
> > Interesting--I didn't know that, and I need to think about chaning my
> > setup. 
> > Thanks!
> 
> NP, kinda took me by surprise when I first heard it ... but when you sit
> back and think about it, it makes sense that the client device has to
> ask if the SSID is present.

If security if a wireless network is the aim you will be using WPA2.
Nobody is getting through that in a timeframe which makes sense. Hiding
the SSID is very appealing to some people, so they advocate it. It does
nothing for security, one way or the other.

-- 
Brian.

Re: [A bit OT] Diagnosing home network

[Mark Fletcher]

On Sun, May 21, 2017 at 02:18:06PM -, 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
> 

Re: [A bit OT] Diagnosing home network

[Dan Purgert]

rhkra...@gmail.com wrote:
> On Monday, May 22, 2017 08:28:54 AM Dan Purgert wrote:
>
>> Probably WPA2-PSK ("Pre Shared Key") -- just means "password auth".
>> TBH, not having the SSID transmitted is actually LESS secure (overall)
>> than just having it transmit, due to the fact that your client devices
>> (phone, laptop, etc) have to broadcast "hey, I'm looking for SSID,
>> any APs in range have that one?"
>
> Interesting--I didn't know that, and I need to think about chaning my
> setup. 
> Thanks!

NP, kinda took me by surprise when I first heard it ... but when you sit
back and think about it, it makes sense that the client device has to
ask if the SSID is present.

-- 
|_|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

Re: [A bit OT] Diagnosing home network

[rhkramer]

On Monday, May 22, 2017 08:28:54 AM Dan Purgert wrote:

> Probably WPA2-PSK ("Pre Shared Key") -- just means "password auth".
> TBH, not having the SSID transmitted is actually LESS secure (overall)
> than just having it transmit, due to the fact that your client devices
> (phone, laptop, etc) have to broadcast "hey, I'm looking for SSID,
> any APs in range have that one?"

Interesting--I didn't know that, and I need to think about chaning my setup.  
Thanks!

Re: [A bit OT] Diagnosing home network

[Kent West]

On Mon, May 22, 2017 at 9:56 AM, Gene Heskett  wrote:

>
> This IoT stuff is way too damned close to 1984, the book.
>
>
http://anonymous-news.com/11-year-old-shocks-cybersecurity-experts-anything-wi-fi-can-weaponized/

-- 
Kent West<")))><
Westing Peacefully - http://kentwest.blogspot.com

Re: [A bit OT] Diagnosing home network

[Gene Heskett]

On Monday 22 May 2017 08:28:54 Dan Purgert wrote:

> rhkra...@gmail.com wrote:
> > On Saturday, May 20, 2017 09:38:21 AM Gene Heskett wrote:
> >> You'll note no mention of wifi here as its turned off unless I have
> >> children visiting with their smart phones.  wifi is slower, and
> >> subject to being used by the neighbors as I found my net usage
> >> after the kids had been in was up about 80 Gb a month later.
> >
> > You know there are security measures available for WiFi, right?  I
> > do two things, I use one of the more advanced encryption protocols
> > (something like WPA-2 (and maybe some more initials at the end??),
> > and, I have it setup so that it doesn't announce its presence--only
> > if someone knows the name can they try to enter a password and
> > login.
>
> Probably WPA2-PSK ("Pre Shared Key") -- just means "password auth".
> TBH, not having the SSID transmitted is actually LESS secure (overall)
> than just having it transmit, due to the fact that your client devices
> (phone, laptop, etc) have to broadcast "hey, I'm looking for SSID,
> any APs in range have that one?"
>
> If the devices aren't leaving your house (e.g. your Nest thermostat,
> or similar) it's a bit of "6 one way / half dozen the other", and
> won't really matter.

Very carefully, old fart-itis probably at work, none of that stuff 
resides here. This IoT stuff is way too damned close to 1984, the book.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: [A bit OT] Diagnosing home network

[Dan Purgert]

rhkra...@gmail.com wrote:
> On Saturday, May 20, 2017 09:38:21 AM Gene Heskett wrote:
>> You'll note no mention of wifi here as its turned off unless I have
>> children visiting with their smart phones.  wifi is slower, and subject
>> to being used by the neighbors as I found my net usage after the kids
>> had been in was up about 80 Gb a month later. 
>
> You know there are security measures available for WiFi, right?  I do two 
> things, I use one of the more advanced encryption protocols (something
> like WPA-2 (and maybe some more initials at the end??), and, I have it
> setup so that it doesn't announce its presence--only if someone knows
> the name can they try to enter a password and login.

Probably WPA2-PSK ("Pre Shared Key") -- just means "password auth".
TBH, not having the SSID transmitted is actually LESS secure (overall)
than just having it transmit, due to the fact that your client devices
(phone, laptop, etc) have to broadcast "hey, I'm looking for SSID,
any APs in range have that one?"

If the devices aren't leaving your house (e.g. your Nest thermostat, or
similar) it's a bit of "6 one way / half dozen the other", and won't
really matter.

-- 
|_|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

Re: [A bit OT] Diagnosing home network

[Gene Heskett]

On Sunday 21 May 2017 12:58:05 rhkra...@gmail.com wrote:

> On Saturday, May 20, 2017 09:38:21 AM Gene Heskett wrote:
> > You'll note no mention of wifi here as its turned off unless I have
> > children visiting with their smart phones.  wifi is slower, and
> > subject to being used by the neighbors as I found my net usage after
> > the kids had been in was up about 80 Gb a month later.
>
> You know there are security measures available for WiFi, right?  I do
> two things, I use one of the more advanced encryption protocols
> (something like WPA-2 (and maybe some more initials at the end??),
> and, I have it setup so that it doesn't announce its presence--only if
> someone knows the name can they try to enter a password and login.

As of the last time, the SSID broadcast had been turned of, WPA-2+AES was 
the effective login protocol with a 23 character password .  That didn't 
appear to much of an impediment, so I just turned the radios off.

First, they came in thru the buffalo I'm looking at, then they came in 
thru the pi's radio when it came online, which was still set at the 
default jessie on a pi settings.  I've got cat5 enough to connect 
everything I want on-line up. I assume one can buy for a winders box, 
some sort of a utility that can survey the band, and hack into the 
strongest signal it can find in a time frame thats 0.1% of 
what the cryptographers claim. So I take the ultimate hammer to it by 
turning off my radios.  Making a wifi connection work like a wired 
connection is a major PITA.  I had my lappy rigged, about 6 feet from my 
lathe, and I'd have to login fresh about every 5 minutes. 9 feet from a 
dongle plugged into the lappy to a matching dongle plugged into the 
buildings hub?  Life, remaining life anyway since I'm working on my 83rd 
trip around this star, is too short for that BS.  Screw it, its 
extremely distracting when your train of thought is on writing gcode for 
the lathes next cnc operation.  Plug it in and be done with that BS.  So 
I do.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: [A bit OT] Diagnosing home network

[rhkramer]

On Saturday, May 20, 2017 09:38:21 AM Gene Heskett wrote:
> You'll note no mention of wifi here as its turned off unless I have
> children visiting with their smart phones.  wifi is slower, and subject
> to being used by the neighbors as I found my net usage after the kids
> had been in was up about 80 Gb a month later. 

You know there are security measures available for WiFi, right?  I do two 
things, I use one of the more advanced encryption protocols (something like 
WPA-2 (and maybe some more initials at the end??), and, I have it setup so 
that it doesn't announce its presence--only if someone knows the name can they 
try to enter a password and login.

Re: [A bit OT] Diagnosing home network

[Dan Purgert]

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

Re: [A bit OT] Diagnosing home network

[David Christensen]

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

Re: [A bit OT] Diagnosing home network

[Celejar]

On Sat, 20 May 2017 14:41:20 +0900
Mark Fletcher  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

Re: [A bit OT] Diagnosing home network

[Catherine Gramze]

> On May 20, 2017, at 9:38 AM, Gene Heskett  wrote:
> 
>> On Saturday 20 May 2017 01:41:20 Mark Fletcher 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.
>> 
>> 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. 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.

>> .
>> 
>> Thanks in advance
>> 
>> Mark

>  Delurking. Just a quick suggestion here. Do you have the proprietary 
> non-free firmware installed for all your NICs? When they work without the 
> firmware it is often a much slower connection, like b when the NIC is capable 
> of n or a/c, but only when using the proprietary firmware. 

Cathy
> 

Re: [A bit OT] Diagnosing home network

[Gene Heskett]

On Saturday 20 May 2017 01:41:20 Mark Fletcher 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.
>
> 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. 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). 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.
>
> Thanks in advance
>
> Mark

Couple things here. I have no such problems. My routing is from the cable 
modem, to a buffalo netfinty router running dd-wrt, so I need no 
firewall. dd-wrt has very sharp teeth so I don't seem to need an 
additional guard dog. The output of the buffalo hits an 8 port managed 
switch, and everything else is plugged into that switch. There are 2 
more switch/hubs plugged into that switch so that one cable to the 
garage hitting an 8 port switch in the garage that feeds 3 machines 
there, and another cable thats been blowing in the wind for about 15 
years now, runs from the house to a 12x16 shop building in the upper 
rear corner of the back yard, where always 2, and occasionally a 3rd 
machine is plugged into a 4 port hub.  The 2 8 port switches and the hub 
are gigahertz capable.  Even the machines in the shop building can 
access the internet at megabyte+ a second speeds.  Amanda hits them all 
at about 1:30 am, and even then, with that load on this machine slowing 
it some, I don't notice a huge networking data slowdown.

You'll note no mention of wifi here as its turned off unless I have 
children visiting with their smart phones.  wifi is slower, and subject 
to being used by the neighbors as I found my net usage after the kids 
had been in was up about 80 Gb a month later. I don't couple the wifi to 
my net, only to the internet, but inspecting dd-wrt's list of dhcpd'd 
net leases disclosed that a neighbor seemed to have discovered it and 
was helping himself to my bandwidth. So I had to log back into the 
buffalo and turn the radio off again. As the garage has vinyl siding, I 
have to do the same thing on a raspberry pi 3b out there, which has an 
excellent wifi, and I had to shut it off too. The raspian-jessie 
defaults enable it, and a dhcpd server, so it was handing out addresses 
and connections on wlan0, using bandwidth I could see.  Ooops.  And I 
have to do it everytime I build a new sd card for it. dhcpcd killed 
forever now, or until I change sd cards.

I configured for future expansion, whereas your setup sounds like its 
machine to machine.  So get a router you can reflash, ditch the 
firewall, and feed the routerr (after setting up NAT in the router to 
put your local network on a local address in the 

Re: [A bit OT] Diagnosing home network

[rhkramer]

On Saturday, May 20, 2017 01:41:20 AM Mark Fletcher wrote:
> 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. 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.

What is the laptop using--802.11a, b, g, n, or ac?

What is the Jessie system using--802.11a, b, g, n, or ac?

(I/m not sure how you can determine this--maybe the LInk Station has a 
"maintainance" screen you can access?)

(Also, the Linkstation has to act as a repeater between the laptop and Jessie 
system--I'm not sure how much that might slow the transfer.)

Anyway, note that the theoretical throughput of 802.11b is 11 Mbps--your 880 
KB/s is reasonably consistent with that.  IIRC, 802.11g can do 54 Mbps, I'm 
not sure about the others.

Re: [A bit OT] Diagnosing home network

[Nemeth Gyorgy]

2017-05-20 07:41 keltezéssel, Mark Fletcher írta:
> 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.
>
For speed measuring I suggest iperf.

[A bit OT] Diagnosing home network

[Mark Fletcher]

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.

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. 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). 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.

Thanks in advance

Mark