On Sun, 2011-10-02 at 11:45 +0200, Radosław Korzeniewski wrote:

> Hello,
> 
> 2011/9/30 reaper <bacula-fo...@backupcentral.com>
> 
>         sounds like your sysctl.conf needs tweaking? have you tried
>         something like this on both sides?
>         
>          kernel.msgmnb = 65536
>          kernel.msgmax = 65536
>          kernel.shmmax = 68719476736
>          kernel.shmall = 4294967296
>         
> 
> 

These are the IPC (inter process communication) kernel parameters and
have nothing about network tuning and AFAIK Bacula doesn't use IPC. I'm
not suprised that there was no effect. :)

hi radoslaw, hi reaper,

yes -- i have just sniffed to some traffic and done a backup over
100mbit network -- here are the results

zurich running bacula-dir and bacula-sd (backup server)
copenhagen running bacula-fd (backup client)

heres the 3 way handshake (bolding is mine)

No.     Time        Source                Destination           Protocol
Info
      1 0.000000    zurich         copenhagen        TCP      33252 >
bacula-fd [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSV=2129448587
TSER=0 WS=6

Frame 1: 76 bytes on wire (608 bits), 76 bytes captured (608 bits)
Linux cooked capture
Internet Protocol, Src: zurich (zurich), Dst: copenhagen (copenhagen)
Transmission Control Protocol, Src Port: 33252 (33252), Dst Port:
bacula-fd (9102), Seq: 0, Len: 0
    Source port: 33252 (33252)
    Destination port: bacula-fd (9102)
    [Stream index: 0]
    Sequence number: 0    (relative sequence number)
    Header length: 40 bytes
    Flags: 0x02 (SYN)
    Window size: 5840
    Checksum: 0xa51b [validation disabled]
    Options: (20 bytes)
        Maximum segment size: 1460 bytes
        TCP SACK Permitted Option: True
        Timestamps: TSval 2129448587, TSecr 0
        NOP
        Window scale: 6 (multiply by 64)

No.     Time        Source                Destination           Protocol
Info
      2 0.000036    copenhagen        zurich         TCP      bacula-fd
> 33252 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1
TSV=1494684643 TSER=2129448587 WS=8

Frame 2: 76 bytes on wire (608 bits), 76 bytes captured (608 bits)
Linux cooked capture
Internet Protocol, Src: copenhagen (copenhagen), Dst: zurich (zurich)
Transmission Control Protocol, Src Port: bacula-fd (9102), Dst Port:
33252 (33252), Seq: 0, Ack: 1, Len: 0
    Source port: bacula-fd (9102)
    Destination port: 33252 (33252)
    [Stream index: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 40 bytes
    Flags: 0x12 (SYN, ACK)
    Window size: 5792
    Checksum: 0xa123 [validation disabled]
    Options: (20 bytes)
        Maximum segment size: 1460 bytes
        TCP SACK Permitted Option: True
        Timestamps: TSval 1494684643, TSecr 2129448587
        NOP
        Window scale: 8 (multiply by 256)
    [SEQ/ACK analysis]

No.     Time        Source                Destination           Protocol
Info
      3 0.023054    zurich         copenhagen        TCP      33252 >
bacula-fd [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=2129448610
TSER=1494684643

Frame 3: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
Linux cooked capture
Internet Protocol, Src: zurich (zurich), Dst: copenhagen (copenhagen)
Transmission Control Protocol, Src Port: 33252 (33252), Dst Port:
bacula-fd (9102), Seq: 1, Ack: 1, Len: 0
    Source port: 33252 (33252)
    Destination port: bacula-fd (9102)
    [Stream index: 0]
    Sequence number: 1    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 32 bytes
    Flags: 0x10 (ACK)
    Window size: 5888 (scaled)
    Checksum: 0xe61d [validation disabled]
    Options: (12 bytes)
        NOP
        NOP
        Timestamps: TSval 2129448610, TSecr 1494684643
    [SEQ/ACK analysis]



zurich and copenhagen are 22.589 ms apart on a shared 100mbit connection
-- using the bandwidth delay product:

theoretical
bandwidth       delay        productBits         bitsPerByte
bytesInWindow
500 000 000 * .022589 = 11 294 50             /   8                =  1
411 813

actual
windowSizeBytes      windowScale      bytesInWindow
delay            throughputBytesPerSecond
bitsPerSecond    
5840                        *  64                   =    373 760
zurich -> copenhagen      / .022589          16 546 107
* 8         132 368 856
5888                        *  256                 = 1 507 328
copenhagen -> zurich      / .022589          66 728 408
* 8         533 827 264



i backed up about 16GB of data uncompressed from copenhagen to zurich at
around 60mbits/s.



i am lost as far as bacula's window calculation -- it thinks that i have
a 500mbit connection?


cheers

m




<<attachment: bacula-1.jpeg>>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to