Server Installation 2020

[Penri]

Hello

Just flipping this on it's head for a moment:

How much bandwidth does the VPN server need when we're doing whatever we want/need to do and how would this impinge on the other users of the internet connection?

I'm not looking for immediate or seat of the pants answers I just want to ensure that whatever we do has minimal, preferably, no impact on the other internet dependant WMT services. I'm assuming all the WMT services activity will be during normal operating hours plus an hour of so before and after.

Very shortly, I hope, we'll have a 40Mb/s downstream : 10Mb/s upstream connection running so this will become a moot point.

Penri

[TerryJC]

How much bandwidth does the VPN server need when we're doing whatever we want/need to do and how would this impinge on the other users of the internet connection?

I'm not looking for immediate or seat of the pants answers I just want to ensure that whatever we do has minimal, preferably, no impact on the other internet dependant WMT services. I'm assuming all the WMT services activity will be during normal operating hours plus an hour of so before and after.

Penri,

I sure that Hamish will also have an opinion on this but my understanding is that the problems that we had weren't directly related to bandwidth. The problem was caused by the high MTU value which (I suspect) is lowered by the provider when bandwidth is a bit scarce to make the connected devices appear more responsive.

In any case, even when we are downloading files from a Pi, we aren't really going to hog the bandwidth because our data is coming back to us over the uplink, which users of the Internet on site will be mainly using to request web pages etc. Those devices such which do use the uplink for data, such as in the shop and cafe, will be using very little anyway so it shouldn't have a major affect on them. The main time that bandwidth we will be taking data from the downlink is when Pis are being updated (either OS updates or Software Framework updates) because data is then coming from the Internet to the Pis. If that ever became a problem, we could confine those activities to before 10 am or after 5 pm.

[hamishmb]

I think downloading isn't likely to be too big of an issue as we get about 1 MB/s down. Uploading on the other hand...

I don't know how the PoS systems work, but I doubt they're very happy with the uplink speed as it is.

There's a tool called wondershaper that we could install first, that allows you to limit the bandwidth on each interface.

Syntax is bascally:

Code: Select all

wondershaper [interface] [downlink] [uplink]

Where downlink and uplinks speeds are in kilobits per second.

So, for example, if we want to use half the available download speed and half the upload, we could do something like:

Code: Select all

wondershaper eth0 4096 256

This would slow it down, but make sure we don't interfere too much with other things. I think it's eth0 on the internet-facing side on the VPN server, but not sure.

[TerryJC]

I don't know how the PoS systems work, but I doubt they're very happy with the uplink speed as it is.

I believe the opposite, but am prepared to be re-educated. When a transaction occurs the two devices only have to do a key exchange and then send and receive a few numbers. When PoS machines are slow in shops etc, I always understood that this was due to the sheer number of shops trying to connect to the server.

In some shops, the response time is much quicker, but I don't think that is necessarily to do with the diameter of the pipe between the shop and the bank, but more to do with how much bandwidth the banks allocate to them.

As I say, I'm prepared to be re-educated. In any case, if we limit our use of the link to simple commands during Opening Times and do network heavy transactions before or after that time, we should be OK,

[TerryJC]

Apropos the above discussion about hogging bandwidth, I was able to update all the Pis this morning before 9 am. I rebooted all but sumppi which I left until I was able to ensure that someone was around if the River System went awry. Nick was there and at around 8:30 sumppi was successfully rebooted.

I encountered one anomaly during this exercise; after sumppi and g4gatepi had rebooted, I was unable to log back in directly (eg ssh from my desktop). However, I was able to log into both Pis from the Webserver Pi, so I was pretty comfortable. After I had updated the VPN Server and reconnected. i was able to log in directly again.

Also apropos the bandwidth discussion, I have come up with a strategy to reduce the bandwidth consumed when downloading Results and Log files. If we compress the files on each Pi, instead of downloading the individual files as I used to do pre-lockdown, we should be able to reduce the size of the files from approximately 200 MB all up to around 5 or 6 MB. My suggestion is that the contents of both the readings and logs directories should be moved to a holding directory in the Pi User's home directory and compressed in place. The resulting zip file can then be retrieved later.

[Penri]

Hello

I must apologies if I've caused needless extra work with my question on bandwidth requirement, that was not what I intended.

I'm very happy that we can deal with whatever needs our systems have without the other users being in any way impacted.

Apologies again.

Penri

[TerryJC]

Apologies again.

No need to apologise. It needed thinking about.

[TerryJC]

I encountered one anomaly during this exercise; after sumppi and g4gatepi had rebooted, I was unable to log back in directly (eg ssh from my desktop). However, I was able to log into both Pis from the Webserver Pi, so I was pretty comfortable. After I had updated the VPN Server and reconnected. i was able to log in directly again.

This wasn't quite right. I thought I had logged in directly, but as the politicians say 'I misremembered'. As of now, I can no longer log directly into either sumppi of g4gatespi, although I can login second hand from wbuttspi.

I've had a rummage around in dhcpcd.conf etc on both Pis and cannot find anything wrong. However, this is exactly the same symptoms as we had when Penri re-installed the VPN Server on Wednesday. Power cycling the Big Switch cured that so maybe that's going to be an ongoing problem, although I can't think why.

I'll keep trying over the coming days to see if the Big Switch relearns the routes on it's own.

[TerryJC]

I have come up with a strategy to reduce the bandwidth consumed when downloading Results and Log files. If we compress the files on each Pi, instead of downloading the individual files as I used to do pre-lockdown, we should be able to reduce the size of the files from approximately 200 MB all up to around 5 or 6 MB. My suggestion is that the contents of both the readings and logs directories should be moved to a holding directory in the Pi User's home directory and compressed in place. The resulting zip file can then be retrieved later.

OK. I've just moved all the Logs and Readings on sumppi, g4gatepi and wbuttspi into a holding directory called /home/pi/ReadingsandLogs in each case, zipped them up (I had to install zip first) and then renamed the resulting zip file to provide a date and source identifier (eg '2020-07-24_wbuttspi_readingsandlogs.zip').

This evening I will retrieve those zipped up files from each device and publish them in the River System Status Topic as I used to do before.

This has left the Readings and logs directories on each Pi empty except for the new files generated by the software.

[Penri]

Terry

I'll be visiting WMT within the next half hour for a few minutes, I can cycle the big switch then if required.


Penri