Re: Ethernet question

Graham J wrote:
[snip]

No, not saying people are wrong - I'm just trying to understand the
relationship between 100Mb or Gb ethernet and the bit rate or size of
the pipe needed. It's not easy to find (and understand) the
information

Suppose you have a computer, network switch, and server, all connected using 100mbit/sec full duplex ethernet.

<snip>

Sorry to runcate the post Graham, but I realised there is something the OP doesn't understand that iis very simply expressed.

There are two aspects to any link. Data transfer rate and latency. Latency is the round trip time for a packet to get to one end, and get a response back.

Latency is a function of size of packet over transfer speed, plus any delays in buffering (or actual transmission) there may be.


So e.g a 64byte packet might take a millisecond there and a millisecond back over a 64kbytes/second link - about 512Kbps.

If its a satellite link that has to go to a geostationary satellite, it has to go a lot further, and might take as much as 1/2 second.


But for most terrestrial stuff the actual time delay is small even cables and fibvres are are around IIRC 200k miles per second, so the delay on a 150 mile link is less than a millisecond. For a typical 1400 byte packet on a 2Mbps line, teh line speed will slow the thing more than that.

Anyway the pint to make here is that what can slow a LAN application like file sharing, down, is more about the latency than the actual pipe size.I remote mount a server ober a 60 mile link tat is actually probably via london - straight SMB over the internet - and the thing that cripples is is not te actual speed of file transfer, but the lots of little packets flying back and forward. SMB (windows file sharing protocol) is not a good protocol for file transfer over WAN links. If I have to do a big transfer I use FTP.

However, when connecting to the web server at that site, the response is hardly different than from using the same code and server in this room: the overwhelming speed problems are simply in the time it takes my browser to render the code into a visible screen, and the speed of the javascript engines.

That's because the HTTP protocol. like email and FTP, was designed for a WAN environment. You request a page, and it comes in a (compressed?) lump.

This offers a solution to one problem: we have many at-home contributors of data. My solution was to allow them to upload to the server, and then allow any 'super user' to download..By absolutely making that bit of data only writable by its author, but sharable by all for read, the problem of locking is solved.

OK, whats the point of all this? well the point is that trying to extend LAN technology across a WAN is VERY expensive. You need high bandwidth uncluttered pipes that may actually only be that fast because you need the low latency to get acceptable performance. The rest of the pipe is wasted.

There are two ways out of this: one is to use a VPN across the internet (or other packet chargeable type shared network) , which will get you shared access to a fast pipe at much lower cost, so your latency will be low, but you wont be paying full price for the whole link. As that is shared by the rest of the internet community.

So compare the cost of a couple of good VPN capable Cisco routers, plus a pair of - say 20Mbp internet links at each end..with a 20Mbps pipe connecting the sites directly.


The other way is to take a step up the protocol ladder, and see what the data being transferred is all about, and redesign the applications to take advantage of much leaner WAN type protocols.

Of course at all levels getting rid of MS based servers is to be advised ...;-)

Also applications that depend on shared file access rather than e.g. proper database engines.


Mail shouldn't be a problem . Set up a corporate linux/IMAP sever and use that.

If this is a typical office setup it will have loads of WORD documents, loads of mail, and a smattering of power point and spreadsheet documents, all of which COULD be stored in a database, and booked out and checked in if needed for editing, or just downloaded to view.. and any corporate databases SHOULD be running on e.g. a web based form type setup.

ere should be almost zero NEED for file sharing.




.

Relevant Pages

  • Re: Ethernet question
    ... the pipe needed. ... 100mbit/sec full duplex ethernet. ... Data transfer rate and latency. ... Latency is a function of size of packet over transfer speed, ...
    (uk.telecom.broadband)
  • Re: simple, adaptive bandwidth throttling with ipfw/dummynet ?
    ... but I'm not sure if it's the last packet into or out of the queue. ... 'Queued' refer to bytes and packets for that bucket currently queued ... Juri said he only has one pipe ... average throughput per session. ...
    (freebsd-net)
  • Re: Understanding where dummynet fits into an ipfw ruleset
    ... >>> apply your deny rules first, as once something matches a pipe ... The first rule allows the packet in on the external interface, ... the packet is reinjected at rule 200 when it leaves the pipe after ...
    (freebsd-net)
  • Efficient use of Dummynet pipes in IPFW
    ... we've used "Dummynet" in FreeBSD for bandwidth control. ... pipe or queue will re-emerge at the next rule. ... because the packet can be passed on to the rules that block ports. ... reinjected into IPFW. ...
    (freebsd-net)
  • Re: Wireless router slows Internet speed
    ... so most folks wouldn't notice. ... A faster link also provides better ... latency. ... Just because the pipe might be restricted to a certain ...
    (alt.internet.wireless)