Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, > I may be going blind, but I still fail to find the type of network > adapter in use. You're not blind, its not mentioned anywhere :-) Its a broadcom: 08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 21) >> $ scp test-data.dd root at fallback: >> test-data.dd 100% 392MB 39.2MB/s 00:10 > SCP isn't a very good test, because you get a lot of overhead for > encryption. Still, this is way below what you seem to expect from your > disk. How ist DRBD supposed to move more than 50MBps through your network? I used scp despite the fact of the overhead because it already shows, that the network-link is capable of way more than 25MB/s. 50MB/s? Where do you get that i expect that? DRBD is configured to a maximum of 25MB/s. What i do expect is that DRBD does a LOCAL speed of more than 1.5MB/s. Please see my earlier emails doing dd with oflag=direct. If i can only do 1.5MB/s locally, why should the network-link be the bottleneck? Why does the load on the master go up while dd'ing, even if the secondary is not attached? And finally: The overall average usage on the drbd-nic is about 1-2MB/s which is far lower than the configured maximum of 25MB/s. The 25MB/s are only saturated during a (re)sync and even the 25MB/s are far less than what the link is capable of (even using scp). It is not the network-link. >> 64 bytes from fallback.content.domain.de.de (80.237.137.130): icmp_seq=3 >> ttl=64 time=0.093 ms > > On a LAN, this is pretty serious latency. Don't expect DRBD to be > whizzing fast in this environment. > You *may* try and opt for protocol B to see if that helps latency, but > you won't solve your throughput issues. Im already using proto B and throughput is definatelly not the problem here. if i can 'create' the problem locally without a secondary attached, how can the network-link be of relevance? - volker