On 2/24/11 1:29 AM, sreenivasulu velpula wrote: > > I have few doubts about mutable file timings. > > + Setup: 193us > * ( What is set up time ?)*
That's the time spent between the decision to modify a file and the start of encryption, which includes permutation of the serverlist and some decisions about where shares ought to go. See https://github.com/warner/tahoe-lafs/blob/master/src/allmydata/mutable/publish.py between lines 140 and 241. > + Encrypting: 91ms (140.17MBps) > + Encoding: 198ms (64.14MBps) > + Packing Shares: 371ms (34.26MBps) > # RSA Signature: 6.0ms > * (what is packing shares and RSA signature ?)* "packing shares" is the time spent arranging the encrypted data into the right format for upload to the servers: some struct.pack() calls, merkle hash tree generation, and the RSA signature operation (called out separately). Each share includes an RSA public-key signature to make sure that only writecap holders can publish valid shares, and the time spend doing RSA signatures is traditionally a performance concern, so the timing report lists it separately, in addition to including it in the overall "Packing Shares" time. Much of the time spent packing the share is O(n) in size of the share, but the RSA signature time is constant. > + Pushing: 15 seconds (830.9kBps) > o Per-Server Response Times: > + [wen34nob]: 3.88s > + [xuqszbmd]: 15 seconds > > * (Is it sum of timings for each segment when u send erasure coded > blocks to servers and getting ACKs from servers ?)* Mutable file publish operations send exactly one message to each server (using a 'test-and-set' method), so those per-server response times are measured from the moment we queue the message for delivery to the time we get the ACK back from the server. Each message contains the erasure-coded share, as well as all the integrity/signature information. hope that helps! -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
