Re: transfer speed data
On Wed 23 Dec 2020 at 20:15:59 (+0200), Andrei POPESCU wrote:
> On Mi, 23 dec 20, 11:48:31, David Wright wrote:
> >
> > Some sort of rough calculation between the expected/nominal bit rate
> > and the actual data rate achieved is certainly useful, if only to
> > ascertain whether the link itself is performing well. For that, you
> > need to reduce the amount of processing (like encryption) of the
> > data, and any other tasks tying up the CPU(s). Just for the test,
> > obviously.
> >
> > If you're still getting poor transfer rates, you might want to swap
> > cables and (if you're dealing with several hardware systems) cards.
> > For example, on the cable front, a cable with damaged blue or brown
> > pairs will give perfect 100BASE-T performance but not 1000BASE-T,
> > which uses all eight wires. (For the same reason, structural wiring
> > using brown for the telephone sockets will have the same problem.)
>
> Let's not forget the source and destination storage (connection).
>
> Even if the Gigabit (per second) interface on the PINE A64+ performs
> pretty well, a transfer larger that can fit in any buffers that might be
> involved will quickly be slowed down to the speed of the SD card and/or
> interface, respectively the USB2 connection for the hard disk (the board
> doesn't have SATA).
I thought Michael Stone had already covered that, by suggesting sparse
files (with which I'm not familiar) and /dev/null for conducting his
encryption tests. I don't think any other posts had covered what's
*between* the PCs, rather than in them.
Common sense would dictate against using SD cards etc for testing
network speeds (unless, say, you were using such files), because you
obviously want to reduce to a minimum the number of points of weakness
(ie slowness), testing the speed of just one link in the chain at a time.
Cheers,
David.
Reply to: