Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Joe, The LDM has several features that add some overhead to inserting a product into the queue in order to deliver that product to the downstream site. If you are strictly looking at transfering a file, then some of the LDM's overhead may not be of interest to you. If you are using pqinsert to insert your products into the data queue, then the program will be computing an MD5 checksum for the product which will be used to uniquely identify the product. This checksum computation is done upon insertion of the product into the queue on the upstream machine, so that time being spent is CPU time, and not network latency. As products become large, the amount of time needed to compute the checksum will increase. The benefit of the MD5 checksum exists in duplicate detection where you have interconnected LDM's or data that can be inserted from more than one location (such as we have with multiple sites ingesting the NOAAPORT data stream and inserting into the IDD from around the country). The MD5 checksum is also capable of being computed on a stream, as opposed to waiting to compute the value once a large file has been composed (pqinsert as mentioned above will be inserting an entire file, and so you will be computing the checksum for the entire file at once and not benefiting from a stream update of the value). The process of inserting the data into the LDM product queue is an additional bit of overhead. As Russ Rew mentioned, the LDM product queue searches are well suited to inserting, delivering, and deleting many products. If you are not sending many files, some of the product queue overhead may be unnecessary. Again, as in the MD5 checksum above, this is not network overhead related. Another feature of the LDM is the ability to provide access to the data stream. Again, if you are only sending completed files, then this feature may not be one that you need. Lastly, the LDM product queue is memory mapped, allowing the distribution of your product to multiple downstream sites as they are ready to receive the product. If you are only transfering the file to a single host, then the additional disk hits are probably not of interest to you- but if you are relaying the file to multiple hosts, then you should see the benefit of the product queue. Steve Chiswell Unidata User Support > > ------- Forwarded Message > > Date: Fri, 29 Mar 2002 14:49:24 -0700 > From: Joe Van Andel <vanandel@xxxxxxxxxxxx> > To: ldm-users@xxxxxxxxxxxxxxxx > cc: anne@xxxxxxxxxxxxxxxx, Russ Rew <russ@xxxxxxxxxxxxxxxx> > Subject: LDM performance vs scp? > > This morning, I was benchmarking file transfers using LDM vs copying the > same file with 'scp'. On the two files I checked, (1237KB and > 2446KB),LDM took 3 times as long to send the file compared to scp. > > Since I'm already short of bandwidth on my T-1 line, I'm quite concerned > that I can not afford to use LDM. > > Has anyone else benchmarked LDM to determine how fast it copies files, > vs alternatives (ftp, http, scp)? > > Any advice on how to improve LDM performance? > > -- > Joe VanAndel > National Center for Atmospheric Research > http://www.atd.ucar.edu/~vanandel/ > Internet: vanandel@xxxxxxxx >
ldm-users
archives: