Absolutely everything is off up there, I'm not going to even bother. You are seriously measuring the downloading of 1 block to do your calculations, which says it all.
Mathematics is not my specialty, so please correct this calculation if you think you can do it better. Like I said before I have a background in political philosophy not mathematics and computer networking. It would be valuable for all of us here to have a better understanding of the actual situation based on empirical evidence.
https://www.reddit.com/r/Bitcoin/comments/38fym5/20mb_block_sizes_requires_at_most_26_mbps/I based my calculation on the discussion on this thread. As you can see my calculation was much more conservative then the OP. If anyone could show how to best calculate what the actual numbers are in regards to blocksize and bandwith I would love to see those numbers, a link or explanation would be great.
Because of protocol overhead, there will be additional data transmitted and received beyond the block contents. There will also be multiple copies of some data transmitted because of multiple connections to/from the node. There will also be dead time in which the bandwidth can not be used because a computer is "computing" and the link is idle. The simple calculations place a lower bound on the bandwidth needed to receive blocks, which is the minimum needed to run a verifying node. If the node is to contribute to the network then it will need additional bandwidth, e.g. to upload data. (If there isn't sufficient upload bandwidth to support the block size, then the node will necessarily be leaching.)
For 10 months I ran a full node off a residential DSL service, including through the spam/loadtests. My DSLservice had approximately 15 Mbps download capability and 1 Mbps upload capability. I limited the number of connections to 30, which seemed to allow slightly more upload bandwidth consumed in a month vs. download bandwidth, i.e. the node was not leeching. So that my other uses of my DSL service didn't choke, I enabled QoS on my router to limit upload bandwidth from the node to 500kbps when there was conflict with other upstream traffic. Based on what I saw, it looks like this node had sufficient network bandwidth to have been able to keep up with 20 MB blocks, at least on average, but it would be close, depending on overhead factors. I would have continued to run this full node to support the network, but after upgrading to bitcoinXT in August the node was DDoSed. I decided to no longer run a full node because of this experience. I did not want to risk the possibility that my ISP would be taken down again by criminals.
In my opinion the only way to settle the question of how much bandwidth is required will be to conduct actual experiments. This will probably show up bottlenecks that simplistic calculations tend to ignore. In addition, it will be necessary to decide what the purpose of the node is, because this will affect the load on the node and the impact of any queuing delays. Mining on my node would be a poor idea even with 1 MB blocks due to a high orphan rate. It would be, and was, more productive to mine with a solo mining pool.) The proper way to do these experiments is to construct a test network of dedicated nodes, DSL simulators, etc... and come up with test workloads, measurement tools, etc... This is a big task, not suitable for hobbyists. With all the VC money out there, however, this is certainly something that could be done.