cancel
Showing results for 
Search instead for 
Did you mean: 

I think VMU is inaccurate

michaelscott
Grafter
Posts: 594
Registered: 09-08-2007

I think VMU is inaccurate

It says that yesterday I used 2GB of bandwidth which is completely ludicrous! I downloaded two ISOs = 1.3GB and then a minimal amount of surfing. Maybe 100MB. So even if it is rounding up, it's wrong! The NIC statistics from my Linux box also substantiate my figures.

Are PlusNet trying to squeeze extra pennies from its customers?
15 REPLIES
hitachi
Grafter
Posts: 343
Registered: 05-04-2007

I think VMU is inaccurate

Dont forget it is upload and download and plus work on 1000 not 1024 to a gig
OldDave
Grafter
Posts: 37
Registered: 03-08-2007

I think VMU is inaccurate

I had a similar problem my usage is normally very low around 40 - 60 mb a day then one day it shot up to 741MB . I queried this with plus net and got a load of very unhelpful replies .
I think there is a bug in VMU database , probably only affects a small minority,
I asked PN to give me details of usage and times - They refused
Makes me wary of switching to a PAYG contract
N/A

I think VMU is inaccurate

michaelscott the amount is right. Divide 2 the total downloaded files to your hard drive. So 1.3GB is 650MB is extra packets which totals 1950MB and then 50MB surfing. Thats why it states 2GB
N/A

I think VMU is inaccurate

forgot to mention, these extra packets are needed to secure and transfer files to your system via through your ip address (extra network connectvity)
Nick_Russell
Grafter
Posts: 553
Registered: 10-05-2007

I think VMU is inaccurate

Sorry walchinc, can't under your answer.

Quote
So 1.3GB is 650MB is extra packets which totals 1950MB


Huh?

How does 2 x 650 = 1950?
N/A

I think VMU is inaccurate

1300MB total downloaded files
/2 = 650MB secure connectivity in download files to your IP address (50%)
--------------------
1950MB total bandwidth for the ISO files
--------------------
50MB surfing the web
-------------------
2000MB Total Connectivity

hope this helps
Nick_Russell
Grafter
Posts: 553
Registered: 10-05-2007

I think VMU is inaccurate

Sorry but clear as mud...maybe I'm being a bit thick.

How do 2 download files of 650MB each come to a total 1950MB. Are you saying each 650MB download has an overhead of 50%, that is 975 MB each?

Not really important I know but I'm trying to understand how the bandwidth is calculated.
Plusnet Staff
Plusnet Staff
Posts: 12,169
Thanks: 18
Fixes: 1
Registered: 04-04-2007

I think VMU is inaccurate

For every file you download there's a certain amount of traffic that is generated to transfer that file across the internet - the overhead data.

This overhead data comes in the form of packet header data (to say which part of the file is being transferred and what sort of packet it is) error correction data (which goes both ways in the form of ack packets to say the data's been received and resent packets for those that fail).

All of this data adds up.
Nick_Russell
Grafter
Posts: 553
Registered: 10-05-2007

I think VMU is inaccurate

I understand this but walchinc seems to be suggesting the overhead is 50% unless I'm reading his post wrong.
N/A

I think VMU is inaccurate

I'd be suprised if the overhead added upto 50%...

Given a reasonable MTU of 1480 bytes and a rwin (amount received before acks are sent of around) of around 32000 bytes and a packet overhead of 38 bytes...

Size of data = 650mb = (size in bytes) / (1480 - 3Cool = 462 packets

462 packets = packets * packet size = 683760 bytes = 683 MB

ACK Packets

Size of data sent = 650 MB = (size in bytes) / (rwin size) = 21 ack packets

Allow 64 bytes for ack packet = 1344 bytes

Total Transferred data = 683 MB + 1 kilobyte so as near as dammit 683 MB sent over the wire.

(This figure though excludes any retransmissions and protocol overheads of establishing the file transfer link and any state information exchanges.)

Allow a packet loss 10% which means we have to transmit 508 packets to get the data over will give 735 MB which is still only 13% increase.

Add in the usual overhead of initial tcp session establishment and the ftp overhead and you'll still only be looking at around 15% increase in size based on 10% retransmission.

So I'd be suprised if the system is requiring 50% overhead...
N/A

I think VMU is inaccurate

quartzconsulting you are reading the posting wrong. I did networking and communications course at Bolton Uni at degree level and I was tryin to write this post on novice level and wanted to be a basic clearer about the amount of bandwidth usage on PN network
Nick_Russell
Grafter
Posts: 553
Registered: 10-05-2007

I think VMU is inaccurate

Sorry but I'm still being a bit thick.

solstans full answer makes perfect sense and would tend to suggest that the original poster's comments about VMU being high having some validity.

I still cannot understant walchinc's comments. Why do you say 2 x 650 MB dowmloads = 1950MB?

Quote
1300MB total downloaded files
/2 = 650MB secure connectivity in download files to your IP address (50%)
--------------------
1950MB total bandwidth for the ISO files


solstans suggests this should be about 735 MB each according to his very clear explanation.
N/A

I think VMU is inaccurate

To confirm my earlier calculations (done with calculator not reality Wink )...

I've just done some fiddling and based on the stats on my ppp0 link (the adsl side of my router) I'm about right on the overhead of roughly 3 - 5% with no retransmission (well assuming 0 retransmission as out 1000 icmp echo packets 0 went astray)...

(I downloaded a file of known size and then compared the before and after packet count/sizes from ifconfig - my router is a DG834 which if you telnet into gives a cut down unix kernel to play with Wink )

Might be worth someone taking a look-see at the VMU code if it is showing a 50% increase - but then again if the OP had a poor link to the site with around 65 - 70% reliablity then the 50% overhead could well start looking better (as links degrade the rwin size can be reduced which in turn means more packets going back as ACK packets etc)
N/A

I think VMU is inaccurate

I was gonna say, for a 650MB file, there is no way in hell your only gonna get 1KB of acks.

Also bear in mind the measurments conventions used in this case, where transfer volume is meaures in 1000MB/GB chunks, whereas filesize is measured in 1024MB/GB chunks.