January 2015 - Asg - mailman3.cels.anl.gov

asg_read() api proposal
by Phil Carns 15 Jan '15

15 Jan '15

I'm looking at how to clean up some of the quirks of the asg.h API today, but the asg_read() API problems are a little deeper than just proposing some argument cleanups, I think. Please bear with me for the long email if you are interested in this topic; it is unavoidably tedious :-) Summary of the current issue (ignoring the verbatim API for the moment): ----------------------------------------- The fundamental problem is that asg_read() is built to support reading an array of records of (possibly) unknown, mixed size. This means that it has to coordinate three things: 1) the number of records requested to be read a) size (count) 2) the memory buffer to read into a) input size (number of bytes) b) output size (number of bytes) 3) the array of record description structs describing the records that were actually read (analogous to probe results). This is critical so that you know where the record boundaries are in the memory buffer that was populated. a) input size (size of array in elements) b) output size (size of array in elements) I've listed 5 different size values above, and technically every single one of them could be different. They are somewhat linked though. For the read to be successful you have to provide values for 2a and 3a that are big enough to handle what you asked to read in 1a. Naively, 3a) has to be as big as 1a), but the record descriptions are intended to be sparse if possible. For example, a single record description can convey that "records 1 through 5000 are all 1-byte and contiguous" without having to hand it 5000 structures. This is essential for efficient storage of 1-byte records. Unfortunately, technically the reader might *expect* a sparse representation but some other client has written some other jumble of records in there and you really do need 5000 elements to describe them all now, or maybe the read will be short because the memory buffer wasn't big enough to hold some unexpectedly large records anyway. In a nutshell it is hard to make a clean API for reading an array of records of nondeterministic, mixed size, and this is our only read function, so this has ramifications all over the place. Proposed solution: ------------------ Eliminate asg_read() and replace it with two other functions, with fewer arguments, that are more tailored to common use cases: 1) asg_read_one(): reads exactly one record. 3a and 3b are eliminated because only one record description is needed. 2a and 2b are still needed because the record could have a different size than the caller expected. - use case: a key/value library: you want to read the value associated with a single key. The caller doesn't know how big the value is ahead of time (other than probably some maximum limit defined by the key/val library). 2) asg_read_sequence(): reads a sequence of records. All records *must* be the same size and *must* have contiguous record ids. 3a) and 3b) are still eliminated, because if the records are contiguous and have consistent sizes then you can represent them sparsely with a single record description. We add a new argument, however, indicating the record size that the caller expects. We return an error if a record in there does not match this size. 2a) can be eliminated because it can be derived by record_count*record_len. - use case: file data for a POSIX or IOR library: you want to read big contiguous sets of 1-byte records out of a fork that is used to store file data. The caller can help the implementation a lot, by, in essence, saying "all of these records are going to be exactly the same size; it is Ok to just throw an error if they are not". Neither the caller or implementation have to contingency plan for weird-sized records. The library has screwed something up if that condition does not hold. This split into two functions essentially gives you the ability to either read a record of unknown size *or* read an array of records. Not both at once. The rationale: ----------------- - simplifies API but doesn't change the actual storage model (we still allow variable sized records) - existing implementations (asg_read on sirocco?) don't have to change necessarily, other than to layer asg_read_one and asg_read_sequence atop the old asg_read(). The old asg_read() is a superset of the functionality of both. - radically simplifies pipelining in Triton (because we'll be able to split RDMA transfers into deterministic sizes up front in asg_read_sequence()) - the upcoming batch extensions will still let you express odd combinations of record reads in a single round trip - we could still add other variants (asg_read_something_complicated()) if we have use cases for mixed-size record arrays that aren't met by the batch api Does this seem reasonable? I'm going to go ahead and optimistically sketch out this API change, but I will adapt as I go if there are objections or suggestions to improve it further... -Phil

1 0

Weekly Report
by Luogeng Dai 12 Jan '15

12 Jan '15

Dear All, Last week, we - revisit the prototype code, add doxygen style comments - commit to main repository - merge the latest simulation code - add req queue in authr server simulation code Regards, Luogeng

1 0

Weekly Report
by Gim Jongmin 12 Jan '15

12 Jan '15

Dear All, We modified the batched logging structure to support "rename." Previous design only supports "write" for the logging, but now we added a flag "0/1" to present (write = 0) and (remove = 1) for each metadata log and it was applied to "link" and "rename". It is still unstable now. Sincerely, Jongmin -- Jongmin Gim Post-Doctoral Research Associate Dept. of Elecrical and Computer Enginerring Texas A&M University 333B Wisenbaker College Station, TX 77843-3259 Phone: 979-587-8311

1 0

ANL Weekly Status - 2015012
by Harms, Kevin N. 12 Jan '15

12 Jan '15

Triton: * working on integrating Clemson security prototype with ASG calls * continuing integration with SOS * testing Triton+Mercury+SSM with v0.6.6 SSM version kevin

1 0

Weekly report
by Guoxin Liu 12 Jan '15

12 Jan '15

Dear All, In the last week, we finished testing the load balancing algorithms' performance using our simulator, and we were also implementing a real distributed testbed on Amazon EC2 in order to measure the load balancing performance in reality. Best Regards! Guoxin Liu PHD Candidate ECE, Clemson University

1 0

AU Update
by Shane Farmer 12 Jan '15

12 Jan '15

All, Campus is spinning up this week and everyone is getting back online. We are continuing work on research for network aggregation, as well as moving to do some troubleshooting in SSM and get a release of some miscellaneous remaining bugfixes. Shane

1 0

20150112 - Sandia Status
by Danielson, Geoffrey Charles 12 Jan '15

12 Jan '15

All, Last week, Sandia continued working on its client and server in advance of anticipated use by friendly users this year.

1 0

notes from ASG API transaction discussion 2015-01-05
by Phil Carns 06 Jan '15

06 Jan '15

Here are my notes from the conference call yesterday. As always feel free to correct or augment. -Phil

1 0

Auburn
by Anthony Skjellum 05 Jan '15

05 Jan '15

We too are reviewing our deliverables and making a plan for 2015. Auburn doesn't really kickoff till next week in terms of students on campus, so I am here by myself getting caught up :-) Tony Anthony Skjellum, PhD Professor of Computer Science and Software Engineering COLSA Professor of Cybersecurity and Information Assurance Director of the Auburn Cyber Research Center and Lead Cyber Scientist for Auburn Samuel Ginn College of Engineering Auburn University skjellum(a)auburn.edu or skjellum(a)gmail.com cell: +1-205-807-4968 ; office: +1-334-844-6360 CONFIDENTIALITY: This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.

1 0

ANL Weekly Status - 20150105
by Harms, Kevin N. 05 Jan '15

05 Jan '15

We are reviewing our deliverables and making a plan for 2015. kevin

1 0