What algorithm would you use to find the "best" file by speed?

What algorithm would you use to find the "best" file by speed?

Which speed is most important?

  1. Download speed?
  2. Upload speed?
  3. Ping times?

a. An average of all three? b. The total of all three? c. The mean?

Once I have a bunch of speed-tagged ovpn files, there is a need to

*sort* them by fastest file, which is easy enough to sort:

$ ls vpngate_DE_09_Saarland_Neunkirchen_95.88.252.235-vpn149931469.opengw.net_tcp995_20160308_0.46dn_0.38up_738ms.ovpn vpngate_DE_09_Saarland_Neunkirchen_95.88.252.235-vpn149931469.opengw.net_tcp995_20160310_1.22dn_0.51up_582ms.ovpn vpngate_DE_09_Saarland_Neunkirchen_95.88.252.235-vpn149931469.opengw.net_udp1195_20160308_1.07dn_0.17up_325ms.ovpn vpngate_DE_09_Saarland_Neunkirchen_95.88.252.235-vpn149931469.opengw.net_udp1195_20160310_1.50dn_1.59up_320ms.ovpn vpngate_DE_na_na_na_176.199.177.41-vpn281592706.opengw.net_tcp1921_20160310_1.21dn_0.69up_595ms.ovpn vpngate_DE_na_na_na_213.136.71.159-213.136.71.159_udp1195_20160304_5.70dn_1.42up_287ms.ovpn vpngate_DE_na_na_na_213.136.71.159-213.136.71.159_udp1195_20160307_5.60dn_3.63up_284ms.ovpn vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_tcp995_20160304_2.07dn_0.00up_500ms.ovpn vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_tcp995_20160307_0.99dn_0.00up_521ms.ovpn vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_udp1195_20160304_5.55dn_5.54up_278ms.ovpn vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_udp1195_20160307_5.48dn_3.81up_278ms.ovpn vpngate_DE_na_na_na_217.240.31.81-217.240.31.81_udp1195_20160309_0.73dn_0.00up_534ms.ovpn vpngate_DE_na_na_na_217.240.31.81-vpn187314653.opengw.net_udp1195_20160308_2.46dn_0.00up_482ms.ovpn vpngate_DE_na_na_na_5.189.135.48-5.189.135.48_udp1195_20160305_3.37dn_1.48up_299ms.ovpn

$ alias vpnsort='vpnsort.sh' $ cat $(which vpnsort.sh) #!/bin/bash # vpnsort lists speed-tagged files slowest to fastest ls *dn_*up_*ms*.ovpn | awk -F"_" '{print $9,$10,$11,$0}' | sort -n exit 0 ## End ##

$ vpnsort 0.46dn 0.38up 738ms.ovpn vpngate_DE_09_Saarland_Neunkirchen_95.88.252.235-vpn149931469.opengw.net_tcp995_20160308_0.46dn_0.38up_738ms.ovpn 0.73dn 0.00up 534ms.ovpn vpngate_DE_na_na_na_217.240.31.81-217.240.31.81_udp1195_20160309_0.73dn_0.00up_534ms.ovpn 0.99dn 0.00up 521ms.ovpn vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_tcp995_20160307_0.99dn_0.00up_521ms.ovpn 1.07dn 0.17up 325ms.ovpn vpngate_DE_09_Saarland_Neunkirchen_95.88.252.235-vpn149931469.opengw.net_udp1195_20160308_1.07dn_0.17up_325ms.ovpn 1.21dn 0.69up 595ms.ovpn vpngate_DE_na_na_na_176.199.177.41-vpn281592706.opengw.net_tcp1921_20160310_1.21dn_0.69up_595ms.ovpn 1.22dn 0.51up 582ms.ovpn vpngate_DE_09_Saarland_Neunkirchen_95.88.252.235-vpn149931469.opengw.net_tcp995_20160310_1.22dn_0.51up_582ms.ovpn 1.50dn 1.59up 320ms.ovpn vpngate_DE_09_Saarland_Neunkirchen_95.88.252.235-vpn149931469.opengw.net_udp1195_20160310_1.50dn_1.59up_320ms.ovpn 2.07dn 0.00up 500ms.ovpn vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_tcp995_20160304_2.07dn_0.00up_500ms.ovpn 2.46dn 0.00up 482ms.ovpn vpngate_DE_na_na_na_217.240.31.81-vpn187314653.opengw.net_udp1195_20160308_2.46dn_0.00up_482ms.ovpn 3.37dn 1.48up 299ms.ovpn vpngate_DE_na_na_na_5.189.135.48-5.189.135.48_udp1195_20160305_3.37dn_1.48up_299ms.ovpn 5.48dn 3.81up 278ms.ovpn vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_udp1195_20160307_5.48dn_3.81up_278ms.ovpn 5.55dn 5.54up 278ms.ovpn vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_udp1195_20160304_5.55dn_5.54up_278ms.ovpn 5.60dn 3.63up 284ms.ovpn vpngate_DE_na_na_na_213.136.71.159-213.136.71.159_udp1195_20160307_5.60dn_3.63up_284ms.ovpn 5.70dn 1.42up 287ms.ovpn vpngate_DE_na_na_na_213.136.71.159-213.136.71.159_udp1195_20160304_5.70dn_1.42up_287ms.ovpn

Notice the "average" numbers of the penultimate file in the list above may indicate it's faster overall than the last file, which is the fastest by download speed.

So I'm not sure *what* algorithm to use for choosing the "best" speed.

What algorithm would you use to find the "best" file by speed?

Reply to
VPN user
Loading thread data ...

Direction depends majority of data being transferred. :)

Look at results of your samples.

0.46dn 0.38up 738ms.ovpn 0.73dn 0.00up 534ms.ovpn 0.99dn 0.00up 521ms.ovpn 1.07dn 0.17up 325ms.ovpn 1.21dn 0.69up 595ms.ovpn 1.22dn 0.51up 582ms.ovpn 1.50dn 1.59up 320ms.ovpn 2.07dn 0.00up 500ms.ovpn 2.46dn 0.00up 482ms.ovpn 3.37dn 1.48up 299ms.ovpn 5.48dn 3.81up 278ms.ovpn 5.55dn 5.54up 278ms.ovpn 5.60dn 3.63up 284ms.ovpn 5.70dn 1.42up 287ms.ovpn

Above is sorted by download speed; would you pick the best ping time for downloads. :(

That does work with the benefit showing selection times for file name. Your final logic may be able to do away with awk. Example: ls *dn_*up_*ms*.ovpn | sort -V -t '_' --key=9 --key=10

I know when I am sorting package names for highest version I have found it best to use -V instead of -n.

Have you considered the case of picking the highest upload speed if the download speed is the same? You can help that logic by using --key switches. See above example.

Since we are speaking about --key, you can have the user pick which is the best key to pick from and use it in your sort command.

Example: case $_arg1 in -d) _sort_key='--key=9 --key=10' ;; -u) _sort_key='--key=10 --key=9' ;; -p) _sort_key='--key=11 --key=9 --key=10' ;; *) usage "Error: invalid switch $_arg1: ;; esac

_ovpn_fn=$(ls *dn_*up_*ms*.ovpn | sort -V -t '_' $_sort_key | head -1)

Reply to
Bit Twister

I guess I deserved that response! :)

Here me out though, because I'm trying to figure out how the "brain" works first, and then to implement *that* in code.

I think I'm a light-duty user in that I mostly just use the web for searches (where I don't like Google knowing everything that I do) or for reading or watching youtube (low bandwidth stuff) and for text-only Usenet posting.

Once in a great while (like once every few months) I run a torrent, usually to get a movie that is an oldie from the 40s or 50s or 60s which are usually less than a GB in size.

So, the speeds I get on the relatively faster vpngate servers is fine such as this server (5.55dn 5.54up 278ms.ovpn): vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_udp1195_20160304_5.55dn_5.54up_278ms.ovpn

I don't "game" at all, so, I don't know if the "ping" times are relevant to me. Generally I've noticed slow ping times (~> 500ms) are on slow servers (~ Look at results of your samples.

Here's what I was trying to get at, I guess. Notice the last 5 times above. The ping times are about the same, so let's just look at speeds: 3.37dn 1.48up 5.48dn 3.81up 5.55dn 5.54up 5.60dn 3.63up 5.70dn 1.42up

To a "human", it seems the middle one is the best. 5.55dn 5.54up

But *how* did I derive that? I don't know. It just *looks* better to me.

My "human" brain processes this by thinking that the download speeds are all within a "range" (give or take a bit) such that it *looks* like, to my brain, something like this: 3dn 1up 5dn 4up 5dn 5up 5dn 4up 5dn 1up

When I look at it *that* way, the middle numbers seem best to me. 5dn 5up

They're consistent in both directions, and they're reasonably high in both directions even though they weren't the highest in either direction.

So, I guess, I'm trying to figure out what algorithm "my brain" used first, before I can figure out what algorithm to implement in code.

I like that, but I think the "algorithm" should pick that middle file of the last five, which would have been (in the sort above) file number 3 below:

  1. vpngate_DE_na_na_na_5.189.135.48-5.189.135.48_udp1195_20160305_3.37dn_1.48up_299ms.ovpn
  2. vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_udp1195_20160307_5.48dn_3.81up_278ms.ovpn
  3. vpngate_DE_na_na_na_213.136.71.159-vpn755373027.opengw.net_udp1195_20160304_5.55dn_5.54up_278ms.ovpn
  4. vpngate_DE_na_na_na_213.136.71.159-213.136.71.159_udp1195_20160307_5.60dn_3.63up_284ms.ovpn
  5. vpngate_DE_na_na_na_213.136.71.159-213.136.71.159_udp1195_20160304_5.70dn_1.42up_287ms.ovpn

I've modified the one-line vpnsort script to use the "-V" but I think I first need to figure out what algorithm my "brain" used to choose file #3 above instead of file #5.

I thought about double sorts and figured the chances of an *exact* match were slim and rare, but what I think I really want is to do some kind of analysis of both the download and upload (taking ping into account only momentarily, just in case pings suck).

So, mostly I'm trying to figure out what *algorithm* my brain used to choose file #3 in that list above, instead of file #5 (which had the fastest download) or file #3 (because it had the fastest upload).

Thanks for that code snippet.

Your suggestion used things I wasn't familiar with (as I've never had a script take arguments other than a file name), and it didn't work on the first pass so I'll play with it a bit to implement the useful choice mechanism of types of sorts to run to choose the best file.

Reply to
VPN user

Why? You state that you are a low useage user. do you really care about the speed, as long as it is not absurdly slow? Ie, it does not matter.

...

No. If I were wanting to only upload I would choose the last, if I were only uploading the middle. And if I did not care probably the middle one, but would not really care. ( and besides these results are likely HIGHLY time dependant. Ie if I ran it again 5 min later I would get very different results.)

No. Depends on what I want to do.

It has high upload and download times.

And since the results are probably only accurate to 1/2 significant figure (ie even a 3 vs a 5 would not matter, because which was faster would change from time to time).

If one HAS to make a choice the human brain will pick, based on all kinds of totally irrelevant material. Even -- It was first in the list. Or It was printed in blue and I like blue.

So perhaps you should figure out what you want the algorithm to do first.

Because the instructions you sent your brain at that moment were hopelessly vague, so it grabbed something, anything, to make a decision. Decisions are costly. It is hugely taxing on the brain to make decisions so it will make one based on the most irrelevant criteria just so the decision gets made.

Reply to
William Unruh

Nobody, given the choice of a slow server versus a faster server would choose the slower one, even if they're light-duty users.

It's very true one statement you said, and very untrue the other:

  1. It's true that the times are extremely time dependent. Run them twice in the same ten-minute period & results will differ!
  2. It's not really true that only download matters if you only download, since there is almost no such thing as just downloading. There is always a bit of uploading even when downloading, if for no other reason than communication purposes.

Well. To "me" it's pretty clear that "my brain" processes that list and figures out that the middle one was best. The differences between the middle one and the fastest on download wasn't great - but the difference between the middle one and the fastest on upload was great.

My point is that the algorithm that the brain uses is not just to pick the biggest number. At the very least, we round off the numbers in our head - so the algorithm I select should probably round off all numbers to 1 decimal place at most, and probably to zero decimal places in reality.

Yes. But my "brain" didn't select the one with the highest download speed!

So, how does "my brain" seem to compensate to pick the one that had both high download and upload times, but not the highest perhaps of each?

That's the algorithm I'm trying to figure out.

Once I figure out the algorithm, it's a *different* task to implement that algorithm in code.

I do agree that the accuracy is NOT to the two decimal places that we see in the upload/download numbers. You're probably correct that the algorithm should limit the numbers to 1/2 such as 1, 1.5, 2, 2.5,

3, 3.5, etc. Maybe even whole numbers such as 1, 2, 3, 4 are best?

I disagree. Respectfully so.

I think if I figure out a good algorithm, it will pick, out of 1000 files, the best files overall, based on the four available inputs: a. Ping times (preferably Because the instructions you sent your brain at that moment were

I agree that looking at the output of a thousand files would be hard for the brain, but I think I can come up with an algorithm that works.

It would not be the fastest of one item only.

For example, what do you think of this 2-step algorithm? STEP 1: First find the fastest 5% for ping, download, & upload respectively. STEP 2: Then compare the 3 lists to report any files in all 3 lists.

If we can't find files in the top 5% of all three lists, then we check the top 10%, and if still nothing, then we move on to the top 20%, and so on, until we find at least one match.

Is that a good "brain" algorithm?

Reply to
VPN user

Yes, so if download speeds are high but upload are zero you are in trouble. But most home ISP have vastly different upload from download speeds (10MB/s down vs .5MB/s upload) which makes virtually no differnce to the useability.

Well my brain, ( and I am a human) processes it differently depending on what I want to do. So, it would seem what you want is not what a "human" does, but what you do.

Of course, since we really do not care if it is 5.4 or 5.5 especdially when we know that measurement is out by a factor of 2 depending on the time. If it is a critical situation and we know that the numbers actually mean something and we want to download, we will probably pick the one with the fastest download speed, as long as the upload is not absurdly small. Similarly with upload speed. And if we do not care, we do not care.

IF I wanted to download I would pick the one with the highest download speed. If I wanted to upload the highest upload speed. that is now my brain operates.

Since none of us have your brain to study, this is an impossible question to answer, and as I have pointed out, my brain apparently operates differently from yours.

As I said, about half a decimal place is all they are worth. Ie, take the log base 10, multiply by 2, and round off.

You asked how the "human brain" picks things. I was trying to tell you. Now you say that is not a "good algorithm". So you do not want how humand do it, but rather some definition of "good".

Reply to
William Unruh

This makes sense. So would you agree the following is the "algorithm"?

  1. Give download speed the most weight.
  2. Give upload speed a LOT less weight.
  3. Give ping times not much weight at all?

Heh heh heh ... :)

I have to agree that the numbers can be off by a LOT! How much? I don't know. Maybe 50%?

So, I think the "algorithm" will just round up or down to zero decimals. Does that sound reasonable?

I don't do much uploading, as we discussed. Of course, a ZERO on upload would kill this post even, but, as bandwidth goes, I don't upload much (except when sending photos in mail, I guess).

I suspect torrenting needs uploads to earn download speeds though, but I do torrenting maybe 3 or 5 times a year, so it's not all that often done.

I guess your algorithm is to just pick the fastest download speed even if the ping and upload times stink. That seems too simple for me to be effective.

Seems to me a better algorithm is to weigh download as most important but to also care about upload and perhaps care about ping.

Huh? Really? Or are you joking?

My algorithm would be to round to zero decimal places, such that: 3.37dn 1.48up becomes 3dn & 1up 5.48dn 3.81up becomes 5dn & 4up 5.55dn 5.54up becomes 6dn & 6up humand do it, but rather some definition of "good".

Your approach as I try to understand it, is not to choose the the fastest download times but to choose the logarithmic derivation of those download times that results in the largest number.

Do I understand the approach right yet?

Reply to
VPN user

I agree with this approach. See below.

It looks like your brain is sorting first on the total of (dn+up), as follows (note the last column showing the total of dn+up): 3.37dn 1.48up becomes 3dn & 1up (3+1=4) 5.48dn 3.81up becomes 5dn & 4up (5+4=9) 5.55dn 5.54up becomes 6dn & 6up (6+6=12=winner) 5.60dn 3.63up becomes 6dn & 4up (6+4=10) 5.70dn 1.42up becomes 6dn & 1up (6+1=7)

I suspect that a secondary qualification is happening, or even multiple additional qualifications, such as:

- was the winner picked in spite of one of its values being abysmal? In other words, did it float to the top by having an unusually large value coupled with an unusually low value? In this case, no, so the winner survives this round. To code this, perhaps the two values need to be within a certain percentage of each other, and furthermore perhaps its desirable to ensure that the dn value is higher than the up value.

- is ping time really relevant? Unless it's way out of hand, (satellite ISP?), then probably not really relevant.

You can handle these cases, and more, by weighting and/or scoring everything, so that the 'best' result naturally floats to the top in a predictable and repeatable fashion. Maybe dn counts for 60% of the final answer, up counts for another 30%, and ping counts for the last 10%. Weight and score everything, do the math, declare the winner.

Reply to
Char Jackson

That's an interesting observation, because I had not realized that the total of dn + up was what I was using (as long as the up isn't zero). But it must be a little more complex because of the weighting of down greater than up. So, if it was 1dn and 6up, that "7" would be less valuable than the 7 from 6dn and 1up.

Maybe a good algorithm is to double (or triple?) the down number (to give it more weight) and then either add or multiply the up number.

If we multiply times the upload, that automatically handles the case of deprecating a zero upload so we don't have to check if upload is 0.

I agree with you that the algorithm needs to deprecate an unusually high number coupled with an unusually low number.

That makes a LOT of sense!

Consistency between down & up adds extra credit (I think) simply because, in *practice*, the consistent servers seem to be better overall when they are consistently high.

I do not really understand how ping times affect the speeds, because latency isn't the same as bandwidth.

The ping time from my ISP, without VPN, is on the order of 20ms to 50ms, while the VPN ping times are far longer - usually on the order of 200ms to over a thousand ms.

So I'm not sure if ping matters greatly; but I have noticed that those with high ping (roughly over 500ms) usually have lousy results, so, maybe pings would be an if-then-else cutoff speed around 400ms?

BTW, for VOIP, the ping jitter is critical but I'm not using VPN for VOIP. I'm sure latency is critical for gamers too. But that's not me.

That algorithm that I just weight each one out of 100% makes sense.

The good news is that once I have the initial algorithm working in code, then it's relativity easy to tweak, so I think I'll start working on the code now, where there is no doubt the weighting will be on:

  1. The download speed gets most of the weight
  2. The upload counts as well (and hurts if it's 0)
  3. The ping also counts but not very much unless it's a high number
  4. Consistency between down & up adds extra credit (I think)
Reply to
VPN user

The product( geometric mean) ( the average of logarithms) weighs small values much more than large. Thus if download is 15 and upload is 1 that is much smaller than if upload is download is 5 and upload is 2. If you are mainly downloading, that would seem a pretty silly weighting.

It depends on what you want to do.

It does? If you primarily do downloading, why does weighting uploads make any sense at all.

Is that really true? You need to study it. Otherwise this becomes and exercise in "How do I make my prejudices the determining factor".

But it is response. I once had a ISP (Virgin in the UK) where the latency to N Am was about 5 seconds. The download and upload speeds were fine for the time. It made typing on my home computer impossible.

Usually ping times are purely a measure of distance. So this says that your IPS is closer to you than the VPN. Surprize surprize.

Reply to
William Unruh

Based on everyone's input, I have come up with a rudimentary algorithm that I think will work. I only need now to add it to the existing vpnspeed.sh script.

Since I've never done a calculation in a script, I will have to do some research so I will post my script only when it works at least rudimenarily.

If I do it right, the algorithm can be easily tweaked, so, I'm not too worried about getting the algorithm right on the first pass.

Yeah. And no. Most people are similar, which is why ISPs can get away with throttling upload speeds in favor of download speeds for example.

I'm still unsure how or why ping times matter though...

This is a "human experience" artificial intelligence question. In my human experience, when the upload was reported as 0.00, the entire VPN experience sucked.

Fair enough. But, I have a rudimentary algorithm now, so, the real work isn't in the algorithm anymore. It's in implementing that algorithm (since, as you know, I'm just a script noob).

Once I implement the algorithm, if it's reasonably well written, I should be able to tweak it to improve it - so - I'm switching gears from design to writing now.

This is good to know. 5,000 ms isn't so far fetched for these VPNs, although I mostly see speeds in the 500ms to 1000ms range.

I would think a ping inside a VPN would be slower than a ping outside that very same VPN. Here's a test - let's see what happens:

$ vpnwhich.sh vpngate_US_NY_NewYork_Buffalo_198.23.197.184-198.23.197.184_tcp443_20160307.ovpn

$ curl

formatting link
echo 198.23.197.184

$ ping -c3 198.23.197.184 PING 198.23.197.184 (198.23.197.184) 56(84) bytes of data. 64 bytes from 198.23.197.184: icmp_seq=1 ttl=106 time=76.3 ms 64 bytes from 198.23.197.184: icmp_seq=2 ttl=106 time=72.9 ms 64 bytes from 198.23.197.184: icmp_seq=3 ttl=106 time=85.1 ms --- 198.23.197.184 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 72.967/78.155/85.176/5.150 ms

$ vpnspeed.sh Good: Directory where openvpn is currently running is /home/bar/doc/cert/vpn_winners/US Good: Directory for renamed file is /home/bar/doc/cert/vpn_winners/US/renamed Good: File to be renamed is vpngate_US_NY_NewYork_Buffalo_198.23.197.184-198.23.197.184_tcp443_20160307.ovpn Good: All 3 speedtest-cli results are numerical; therefore we can rename the ovpn file... Good: Moving /home/bar/doc/cert/vpn_winners/US/vpngate_US_NY_NewYork_Buffalo_198.23.197.184-198.23.197.184_tcp443_20160307.ovpn to /home/bar/doc/cert/vpn_winners/US/renamed/vpngate_US_NY_NewYork_Buffalo_198.23.197.184-198.23.197.184_tcp443_20160307_4.26dn_0.15up_426ms.ovpn dn speed is 4.26 up speed is 0.15 platency is 426

$ ping -c3 198.23.197.184 PING 198.23.197.184 (198.23.197.184) 56(84) bytes of data. 64 bytes from 198.23.197.184: icmp_seq=1 ttl=106 time=100 ms 64 bytes from 198.23.197.184: icmp_seq=2 ttl=106 time=75.4 ms 64 bytes from 198.23.197.184: icmp_seq=3 ttl=106 time=72.8 ms --- 198.23.197.184 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 72.861/82.992/100.694/12.562 ms

So, on my own ISP, the ping average was 100ms while on VPN the average was 85ms by the ping method, and 426ms by speedtest-cli.

If I discount the speedtest-cli (it's off by over 4x the pings), and if I compare the ping to the VPN server both on and off VPN, you are correct in that they're in the same order of magnitude.

In fact, I'm surprised that the ping times on VPN were actually shorter than the ping times off of VPN!

Reply to
VPN user

If you have any serious math to do, you might look into bc.

echo "scale=10; (215605-3303-212086)/215605" | bc

or just some usual math type stuff not easy with bash _odd_wk=$(echo "$(date '+%_W') % 2" | bc ) echo Is this an odd week of the year (0=yes 1=no) $_odd_wk

Reply to
Bit Twister

This last example is easy to do in bash:

_odd_wk=$(($(date '+%_W') % 2))

Scott

Reply to
Scott Hemphill

Taking your advice to look at "bc" in more detail, I used "bc" just now for the first time, in order to round the floating-point ping time to the nearest integer.

The purpose of this vpnspeed script is merely to determine the speeds and then rename the ovpn file with those speeds. The script that will actually choose the fastest file will be the vpnrun script.

Nonetheless, since this is the first use of "bc", here's the vpnspeed script with the new use of "bc" to round ping numbers to the nearest integer.

#!/bin/bash # File: vpnspeed.sh renames the currently running ovpn file with speed results. # Version: 20160313 # Many thanks to Marek Novotny for patient algorithmic suggestions. # Thanks also to BitTwister for program-flow streamlining guidance.

# Get error checking for free (courtesy of BitTwister). set -u

# Abort if openvpn is not currently running openvpnPID=$(pgrep openvpn) if [ $? -ne 0 ] ; then echo "Oops: There's nothing to do as openvpn isn't running; aborting" exit 1 fi

# Set up the display for the xmessage (courtesy of Marek Novotny). setupDisplay() { if [[ -z "$DISPLAY" ]]; then DISPLAY=':0' fi }

setupDisplay

# Popup message when the speedtest-cli finishes (courtesy of Marek Novotny). sendMessage() { ans=$(xmessage -display $DISPLAY -fg black -bg white \ -title "VPN Speed" -geom +60+30 \ -buttons yes,no -default yes "$1") }

# Obtain the directory that openvpn was last run from: openvpnCWD=$(sudo ls -l /proc/$openvpnPID/cwd | awk '{print $NF}') echo "Good: Directory where openvpn is currently running is $openvpnCWD"

# Define the directory to contain the renamed openvpn file: renameSubDir=${openvpnCWD}/renamed echo "Good: Directory for renamed file is $renameSubDir"

# Obtain the currently running openvpn file name: openvpnFileName=$(cat /proc/$openvpnPID/cmdline | awk -F"--config" '{print $2}' | awk -F"--script" '{print $1}') echo "Good: File to be renamed is $openvpnFileName"

# Create filename variables which will be used more than once below: shortFileName=$(basename $openvpnFileName .ovpn) fullFileSpec=${openvpnCWD}/${openvpnFileName}

# Run a ping as an early speed indicator (because speedtest-cli is slow!): pingAvgFloat=$(ping -c3 8.8.8.8 | grep rtt| awk -F"/" '{print $5}')

# Round the floating point ping time to the nearest integer millisecond: pingRoundInteger=$(echo "($pingAvgFloat+0.5)/1" | bc) echo "Good: Average integer latency to 8.8.8.8 is ${pingRoundInteger}ms"

# Capture speedtest into variables (courtesy of Marek Novotny): IFS=$'\n' set -- $(speedtest-cli --simple --secure --timeout 5) pingResult="${1/*: /}" downResult="${2/*: /}" upResult="${3/*: /}" IFS=$'\t\n ' pingR=${pingResult/.*/} downR=${downResult/' Mbit/s'/} upR=${upResult/' Mbit/s'/}

# Determine if each of the speedtest results are numerical: isnum() { awk -v a="$1" 'BEGIN {print (a == a + 0)}'; } isNumPingR=$(isnum "$pingR") isNumDownR=$(isnum "$downR") isNumUpR=$(isnum "$upR")

# Rename the current ovpn file only if all 3 speedtest-cli results are numerical: if [ "$isNumPingR" == "1" ] && [ "$isNumUpR" == "1" ] && [ "$isNumDownR" == "1" ]; then echo "Good: All 3 speedtest-cli results are numerical; therefore we can rename the ovpn file..." if [ -f $fullFileSpec ]; then echo "Good: Moving $fullFileSpec to ${renameSubDir}/${shortFileName}_${downR}dn_${upR}up_${pingR}ms.ovpn" if [ ! -d "$renameSubDir" ]; then echo "Making $renameSubDir directory" mkdir "$renameSubDir" fi mv "$fullFileSpec" "${renameSubDir}/${shortFileName}_${downR}dn_${upR}up_${pingR}ms.ovpn" echo "dn speed is ${downR}" echo "up speed is ${upR}" echo "platency is ${pingR}" sendMessage "Kill ${downR}dn ${upR}up ${pingR}ms ${openvpnFileName}?" else echo "Oops: $fullFileSpec does not exist; not renaming" exit 1 fi else echo "Oops: Speedtest results are not all numerical; can't rename ${openvpnFileName}" exit 1 fi

exit 0 ## End ##

Reply to
VPN user

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.