arXiv subjects

Greg White

Publications and source records attributed to Greg White.

4 recordsLinked to original sources

arXiv2022

A Fresh Look at ECN Traversal in the Wild

The Explicit Congestion Notification (ECN) field has taken on new importance due to Low Latency, Low Loss, and Scalable throughput (L4S) technology designed for extremely latency-sensitive applications (such as cloud games and cloud-rendered VR/AR). ECN and L4S need to be supported by the client and server but also all devices in the network path. We have identified that "ECN bleaching", where an intermediate network device clears or "bleaches" the ECN flags, occurs and quantified how often that happens, why it happens and identified where in the network it happens. In this research, we conduct a comprehensive measurement study on end-to-end traversal of the ECN field using probes deployed on the Internet across different varied clients and servers. Using these probes, we identify and locate instances of ECN bleaching on various network paths on the Internet. In our six months of measurements, conducted in late 2021 and early 2022, we found the prevalence varied considerably from network to network. One cloud provider and two cellular providers bleach the ECN field as a matter of policy. Of the rest, we found 1,112 out of 129,252 routers, 4.17% of paths we measured showed ECN bleaching.

cs.NI↗

arXiv2002

AIDA: Accelerator Integrated Data Access

All Control Systems that grow to any size have a variety of data that are stored in different formats on different nodes in the network. Examples include sensor value and status, archived sensor data, device oriented support data and relationships, message logs, application and machine configurations etc. Each type of data typically has a different programming interface. Higher-level applications need to access a logically related set of data that is in different data stores and may require different processing. AIDA is envisioned to be a distributed service that allows applications access to this wide variety of Control System data in a consistent way that is language and machine independent. It has the additional goal of providing an object-oriented layer for constructing applications on top of multiple existing conventional systems like EPICS or the SLC Control System. Motivation, design overview and current status will be presented.

physics.acc-ph↗

arXiv2001

An XML Driven Graphical User Interface and Application Management Toolkit

In the past, the features of a user interface were limited by those available in the existing graphical widgets it used. Now, improvements in processor speed have fostered the emergence of interpreted languages, in which the appropriate method to render a given data object can be loaded at runtime. XML can be used to precisely describe the association of data types with their graphical handling (beans), and Java provides an especially rich environment for programming the graphics. We present a graphical user interface builder based on Java Beans and XML, in which the graphical screens are described textually (in files or a database) in terms of their screen components. Each component may be a simple text read back, or a complex plot. The programming model provides for dynamic data pertaining to a component to be forwarded synchronously or asynchronously, to the appropriate handler, which may be a built-in method, or a complex applet. This work was initially motivated by the need to move the legacy VMS display interface of the SLAC Control Program to another platform while preserving all of its existing functionality. However the model allows us a powerful and generic system for adding new kinds of graphics, such as Matlab, data sources, such as EPICS, middleware, such as AIDA[1], and transport, such as XML and SOAP. The system will also include a management console, which will be able to report on the present usage of the system, for instance who is running it where and connected to which channels.

physics.ins-det↗

arXiv2001

COSMIC - The SLAC COntrol System MIgration Challenge

The current SLC control system was designed and constructed over 20 years ago. Many of the technologies on which it was based are obsolete and difficult to maintain. The VMS system that forms the core of the Control System is still robust but third party applications are almost non-existent and its long-term future is in doubt. The need for a Control System at SLAC that can support experiments for the foreseeable future is not in doubt. The present B-Factory or PEPII experiment is projected to run at least 10 years. An FEL laser of unprecedented intensity plus an ongoing series of fixed target experiments is also in our future. The Next Linear Collider or NLC may also be in our future although somewhat farther distant in time. The NLC has performance requirements an order of magnitude greater than anything we have built to date. In addition to large numbers of IOCs and process variables, Physicists would like to archive everything all the time. This makes the NLC Control System a bit like a detector system as well. The NLC Control System will also need the rich suite of accelerator applications that are available with the current SLC Control System plus many more that are now only a glimmer in the eyes of Accelerator Physicists. How can we migrate gradually away from the current SLC Control System towards a design that will scale to the NLC while keeping everything operating smoothly for the ongoing experiments?

physics.acc-ph↗