Hi, On 10/12/2006 3:43 PM, Anders Boström wrote: >>>>>>"AL" == Arno Lehmann <[EMAIL PROTECTED]> writes: > > > AL> Still the network is being used and that always involves latencies, > AL> syncronization times, etc. > >> > >> Yes, and that might be the problem. But if it is about latencies > >> and/or synchronization, then it is a bacula performance problem! > > AL> No, what I'm talking about is network fundamentals. Whenever you send > AL> data across a network that takes time, and it takes more time than > AL> dividing xMBit/s by the amount of data. Always. > > Are you talking about the long-fat-pipe problem? This isn't an issue > for us... Linux has a very good TCP-implementation, with > window-scaling, and we are running over a local GE-network with less > than 50us latency.
No, I just wanted to point out that a network link is always slower than writing to /dev/null, and that even with an unloaded network the network transfer always needs time. When transferring the amounts of data you encounter with a backup application, this does add up, but it's - assuming you've got your network running ok - not possible to avoid. > >> Is bacula limited in performance due to high latency? (Not that we > >> have that problem, but anyway...) > >> > >> Is bacula limited in performance due to synchronization? > > AL> Networks are limited by several factors. That's not something you can > AL> fix, and network throughput is not normally the most limiting factor in > AL> a Bacula setup. > > The specific issue here is about bacula. Has bacula any specific > limitations regarding the network? Please be specific, and don't just > generalize. Unfortunately, I don't have any hard numbers, but as I pointed out in my experience the network is not normally a limiting factor, and I don't know any Bacula-specific limitations. > >> >> But, as you point out, the tar should be faster. It doesn't need to > >> >> write to net. However, not 2 times faster. The net-load is ~1% (10 > >> >> Mbit/s on a GE-network), and *should* not affect the performance in > >> >> this case. > >> > AL> *Should* is not very helpful here... instead, send the tar output > AL> through a netcat to the backup server and write it to disk. For example. > >> > >> But we have two scenarios here: > >> > >> 1. Bacula is affected by a very low network load. > >> > >> 2. Bacula isn't affected by a very low network load. > >> > >> If (1) is true, why??? > > AL> Erm, no, I see no such scenario. I see you claim that a (mostly idle) > AL> network transfers data as fast as a tar > /dev/null which is not true. > > I've never claimed that "network transfers data as fast as a > tar > /dev/null". I only claimed that network performance shouldn't be > a limiting factor in this specific case. Well, your comparison implied that to me. Sorry if I misunderstood you. > / Anders Arno -- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
