Replacement of Noise Injection System
Just a heads up, we are replacing components of the noise injection system, and so it will unavailable until further notice.
Thank you, -Mike Sherman
New (Gen 4) Nodes
Just a short notice to announce the arrival of the 4th generation of ORBIT nodes ( http://www.orbit-lab.org/wiki/Hardware/hNodes/cNodeVer4 ): sb1 now has two lower-power gen4 nodes (which unfortunately means that we don’t have original ORBIT nodes in any of the sandboxes anymore), while high-powered gen4 nodes replaced gen3 nodes supporting USRP X310s in the main grid. Unfortunately, in addition to being faster, new nodes also require more modern kernels (we are still looking into whether we can backport all the necessary drivers) which means that older images, including current Ubuntu 12.04 based baseline.ndz won't work with the new nodes. Currently, the only image that works with these new nodes is baseline-gen4.ndz (that image will also work with all gen3 nodes but will not boot properly on the gen1 and gen2 nodes - newer Ubuntu distributions don’t support non-pae platforms suggesting the end of universal images that run on all ORBIT nodes).
DARPA Spectrum Challenge and ORBIT
As some of you have already heard (and are hopefully participating), the ORBIT testbed will be hosting the upcoming DARPA Spectrum Challenge (http://www.darpa.mil/spectrumchallenge/). While this is great opportunity for our community to show creativity, it also means that (especially in the early rounds) challenge teams will have priority in scheduling access to resources. More pointedly, in the next 4 weeks, the grid and some sandboxes will be reserved up to 16 hours a day exclusively for the Challenge. This will be reflected on the scheduler as blocked time on the grid (you will notice large number of new virtual resources on the scheduler as well) - please refrain from using ORBIT during these hours. Also, in preparation for the actual start of the challenge we will be a.) retiring omf-5.3; b.) pruning the image repository (please delete all images; we will delete all images that have not been touched in the last 6 months); and c.) enhancing the USRP resources available on ORBIT.
Sorry for any inconvenience
please be advised that, as part of the latest infrastructure software upgrade, OMF 5.4.2 was promoted as a default management framework in all ORBIT domains. OMF 5.3 is still available with explicit invocation (i.e. with "/usr/bin/omf-5.3" or just "omf-5.3"). If you were using 5.3 for your experiment execution and want to upgrade to 5.4 you will have to upgrade OMF resource controller (RC) in your image ("apt-get install omf-resctl-5.4") and convert your experimental scripts before running it under the new experiment controller version.
Please be advised that we will be upgrading some of the infrastructure services/machines in the next week or two. As part of this upgrade, we will merge the repositories for OMF 5.2 and OMF 5.3 on repository1 and delete images older than 6 months during the maintenance period on Wednesday; IT IS ESSENTIAL that you make sure time-stamps of all the images you want to keep are less than 6 months old BEFORE this Wednesday, August 2nd (if in doubt, please just log into repository1 and touch the files). As part of this upgrade, we will also retire OMF 5.2, promote OMF 5.3 as a default control framework and introduce OMF 5.4 into ORBIT (for details on new framework features please check mytestbed.net).
Please be advised that we will be upgrading most of our infrastructure machines in the next week or two (as some of you have already noticed, we already upgraded most of the consoles). While we will try to make this as transparent as possible, there is a chance that occasionally things will not work as advertised. Also, as part of this upgrade, we will retire all older versions of OMF (including OMF 5.1) during the maintenance period on Wednesday; if you are still using one of the old versions of OMF OEDL for your experimental scripts, please do let us know and we will help you transition them to OMF 5.2.
New Auto-Approver for Scheduler
We've implemented new auto-approver service which is supposed to do a much better job in resolving conflicting slot reservations and to much more closely follow the official Orbit reservation policy including the automatic daily pre-approval of slots at 2 PM EDT. Please help us test it and let us know if you notice any problems with it.
node1-1@sb5 has been fixed (defective CM was replaced).