I think the primary area where people are concerned about latency are rbd
and 4k block size access. OTOH 2.3us latency seems to be 2 orders of
magnitude below of what seems to be realistically achievable on a real
world cluster anyway (
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-July/
Looking at the latency numbers in this thread, it seems to be a cut-through
switch.
Subhachandra
On Wed, Mar 21, 2018 at 12:58 PM, Subhachandra Chandra <
schan...@grailbio.com> wrote:
> Latency is a concern if your application is sending one packet at a time
> and waiting for a reply. If you are
Latency is a concern if your application is sending one packet at a time
and waiting for a reply. If you are streaming large blocks of data, the
first packet is delayed by the network latency but after that you will
receive a 10Gbps stream continuously. The latency for jumbo frames vs 1500
byte fra
On 21-3-2018 13:47, Paul Emmerich wrote:
> Hi,
>
> 2.3µs is a typical delay for a 10GBASE-T connection. But fiber or SFP+
> DAC connections should be faster: switches are typically in the range of
> ~500ns to 1µs.
>
>
> But you'll find that this small difference in latency induced by the
> switc
Hi,
2.3µs is a typical delay for a 10GBASE-T connection. But fiber or SFP+ DAC
connections should be faster: switches are typically in the range of ~500ns
to 1µs.
But you'll find that this small difference in latency induced by the switch
will be quite irrelevant in the grand scheme of things wh
Hi,
I just ran into this table for a 10G Netgear switch we use:
Fiberdelays:
10 Gbps vezelvertraging (64 bytepakketten): 1.827 µs
10 Gbps vezelvertraging (512 bytepakketten): 1.919 µs
10 Gbps vezelvertraging (1024 bytepakketten): 1.971 µs
10 Gbps vezelvertraging (1518 bytepakketten): 1.905 µs
Co
