Digital Times
Total Page：16
File Type：pdf, Size：1020Kb
Load more
Recommended publications
-
HOW FAST IS RF? by RON HRANAC
Originally appeared in the September 2008 issue of Communications Technology. HOW FAST IS RF? By RON HRANAC Maybe a better question is, "What's the speed of an electromagnetic signal in a vacuum?" After all, what we call RF refers to signals in the lower frequency or longer wavelength part of the electromagnetic spectrum. Light is an electromagnetic signal, too, existing in the higher frequency or shorter wavelength part of the electromagnetic spectrum. One way to look at it is to assume that RF is nothing more than really, really low frequency light, or that light is really, really high frequency RF. As you might imagine, the numbers involved in describing RF and light can be very large or very small. For more on this, see my June 2007 CT column, "Big Numbers, Small Numbers" (www.cable360.net/ct/operations/techtalk/23783.html). According to the National Institute of Standards and Technology, the speed of light in a vacuum, c0, is 299,792,458 meters per second (http://physics.nist.gov/cgi-bin/cuu/Value?c). The designation c0 is one that NIST uses to reference the speed of light in a vacuum, while c is occasionally used to reference the speed of light in some other medium. Most of the time the subscript zero is dropped, with c being a generic designation for the speed of light. Let's put c0 in terms that may be more familiar. You probably recall from junior high or high school science class that the speed of light is 186,000 miles per second. -
Debates in the Digital Humanities This Page Intentionally Left Blank DEBATES in the DIGITAL HUMANITIES
debates in the digital humanities This page intentionally left blank DEBATES IN THE DIGITAL HUMANITIES Matthew K. Gold editor University of Minnesota Press Minneapolis London Chapter 1 was previously published as “What Is Digital Humanities and What’s It Doing in English Departments?” ADE Bulletin, no. 150 (2010): 55– 61. Chap- ter 2 was previously published as “The Humanities, Done Digitally,” The Chron- icle of Higher Education, May 8, 2011. Chapter 17 was previously published as “You Work at Brown. What Do You Teach?” in #alt- academy, Bethany Nowviskie, ed. (New York: MediaCommons, 2011). Chapter 28 was previously published as “Humanities 2.0: Promises, Perils, Predictions,” PMLA 123, no. 3 (May 2008): 707– 17. Copyright 2012 by the Regents of the University of Minnesota all rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Published by the University of Minnesota Press 111 Third Avenue South, Suite 290 Minneapolis, MN 55401- 2520 http://www.upress.umn.edu library of congress cataloging-in-publication data Debates in the digital humanities / [edited by] Matthew K. Gold. ISBN 978-0-8166-7794-8 (hardback)—ISBN 978-0-8166-7795-5 (pb) 1. Humanities—Study and teaching (Higher)—Data processing. 2. Humanities —Technological innovations. 3. Digital media. I. Gold, Matthew K.. AZ182.D44 2012 001.3071—dc23 2011044236 Printed in the United States of America on acid- free paper The University of Minnesota is an equal- opportunity educator and employer. -
Low Latency – How Low Can You Go?
WHITE PAPER Low Latency – How Low Can You Go? Low latency has always been an important consideration in telecom networks for voice, video, and data, but recent changes in applications within many industry sectors have brought low latency right to the forefront of the industry. The finance industry and algorithmic trading in particular, or algo-trading as it is known, is a commonly quoted example. Here latency is critical, and to quote Information Week magazine, “A 1-millisecond advantage in trading applications can be worth $100 million a year to a major brokerage firm.” This drives a huge focus on all aspects of latency, including the communications systems between the brokerage firm and the exchange. However, while the finance industry is spending a lot of money on low- latency services between key locations such as New York and Chicago or London and Frankfurt, this is actually only a small part of the wider telecom industry. Many other industries are also now driving lower and lower latency in their networks, such as for cloud computing and video services. Also, as mobile operators start to roll out 5G services, latency in the xHaul mobile transport network, especially the demanding fronthaul domain, becomes more and more important in order to reach the stringent 5G requirements required for the new class of ultra-reliable low-latency services. This white paper will address the drivers behind the recent rush to low- latency solutions and networks and will consider how network operators can remove as much latency as possible from their networks as they also race to zero latency. -
Timestamp Precision
Timestamp Precision Kevin Bross 15 April 2016 15 April 2016 IEEE 1904 Access Networks Working Group, San Jose, CA USA 1 Timestamp Packets The orderInfo field can be used as a 32-bit timestamp, down to ¼ ns granularity: 1 s 30 bits of nanoseconds 2 ¼ ms µs ns ns Two main uses of timestamp: – Indicating start or end time of flow – Indicating presentation time of packets for flows with non-constant data rates s = second ms = millisecond µs = microsecond ns = nanosecond 15 April 2016 IEEE 1904 Access Networks Working Group, San Jose, CA USA 2 Presentation Time To reduce bandwidth during idle periods, some protocols will have variable rates – Fronthaul may be variable, even if rate to radio unit itself is a constant rate Presentation times allows RoE to handle variable data rates – Data may experience jitter in network – Egress buffer compensates for network jitter – Presentation time is when the data is to exit the RoE node • Jitter cleaners ensure data comes out cleanly, and on the right bit period 15 April 2016 IEEE 1904 Access Networks Working Group, San Jose, CA USA 3 Jitter vs. Synchronization Synchronization requirements for LTE are only down to ~±65 ns accuracy – Each RoE node may be off from TAI by up to 65 ns (or more in some circumstances) – Starting and ending a stream may be off by this amount …but jitter from packet to packet must be much tighter – RoE nodes should be able to output data at precise relative times if timestamp is used for a given packet – Relative bit time within a flow is important 15 April 2016 IEEE 1904 Access -
The Evolution of the Unix Time-Sharing System*
The Evolution of the Unix Time-sharing System* Dennis M. Ritchie Bell Laboratories, Murray Hill, NJ, 07974 ABSTRACT This paper presents a brief history of the early development of the Unix operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system. NOTE: *This paper was first presented at the Language Design and Programming Methodology conference at Sydney, Australia, September 1979. The conference proceedings were published as Lecture Notes in Computer Science #79: Language Design and Programming Methodology, Springer-Verlag, 1980. This rendition is based on a reprinted version appearing in AT&T Bell Laboratories Technical Journal 63 No. 6 Part 2, October 1984, pp. 1577-93. Introduction During the past few years, the Unix operating system has come into wide use, so wide that its very name has become a trademark of Bell Laboratories. Its important characteristics have become known to many people. It has suffered much rewriting and tinkering since the first publication describing it in 1974 [1], but few fundamental changes. However, Unix was born in 1969 not 1974, and the account of its development makes a little-known and perhaps instructive story. This paper presents a technical and social history of the evolution of the system. Origins For computer science at Bell Laboratories, the period 1968-1969 was somewhat unsettled. The main reason for this was the slow, though clearly inevitable, withdrawal of the Labs from the Multics project. To the Labs computing community as a whole, the problem was the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system, let alone the panacea envisioned earlier. -
Open Geospatial Consortium
Open Geospatial Consortium Submission Date: 2016-08-23 Approval Date: 2016-11-29 Publication Date: 2016-01-31 External identifier of this OGC® document: http://www.opengis.net/doc/geosciml/4.1 Internal reference number of this OGC® document: 16-008 Version: 4.1 Category: OGC® Implementation Standard Editor: GeoSciML Modelling Team OGC Geoscience Markup Language 4.1 (GeoSciML) Copyright notice Copyright © 2017 Open Geospatial Consortium To obtain additional rights of use, visit http://www.opengeospatial.org/legal/. IUGS Commission for the Management and Application of Geoscience Information, Copyright © 2016-2017. All rights reserved. Warning This formatted document is not an official OGC Standard. The normative version is posted at: http://docs.opengeospatial.org/is/16-008/16-008.html This document is distributed for review and comment. This document is subject to change without notice and may not be referred to as an OGC Standard. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. Document type: OGC® Standard Document subtype: Document stage: Approved for Publis Release Document language: English i Copyright © 2016 Open Geospatial Consortium License Agreement Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement. -
Discovery of Frequency-Sweeping Millisecond Solar Radio Bursts Near 1400 Mhz with a Small Interferometer Physics Department Senior Honors Thesis 2006 Eric R
Discovery of frequency-sweeping millisecond solar radio bursts near 1400 MHz with a small interferometer Physics Department Senior Honors Thesis 2006 Eric R. Evarts Brandeis University Abstract While testing the Small Radio Telescope Interferometer at Haystack Observatory, we noticed occasional strong fringes on the Sun. Upon closer study of this activity, I find that each significant burst corresponds to an X-ray solar flare and corresponds to data observed by RSTN. At very short integrations (512 µs), most bursts disappear in the noise, but a few still show very strong fringes. Studying these <25 events at 512 µs integration reveals 2 types of burst: one with frequency structure and one without. Bursts with frequency structure have a brightness temperature ~1013K, while bursts without frequency structure have a brightness temperature ~108K. These bursts are studied at higher frequency resolution than any previous solar study revealing a very distinct structure that is not currently understood. 1 Table of Contents Abstract ..........................................................................................................................1 Table of Contents...........................................................................................................3 Introduction ...................................................................................................................5 Interferometry Crash Course ........................................................................................5 The Small Radio Telescope -
Microsecond and Millisecond Dynamics in the Photosynthetic
Microsecond and millisecond dynamics in the photosynthetic protein LHCSR1 observed by single-molecule correlation spectroscopy Toru Kondoa,1,2, Jesse B. Gordona, Alberta Pinnolab,c, Luca Dall’Ostob, Roberto Bassib, and Gabriela S. Schlau-Cohena,1 aDepartment of Chemistry, Massachusetts Institute of Technology, Cambridge, MA 02139; bDepartment of Biotechnology, University of Verona, 37134 Verona, Italy; and cDepartment of Biology and Biotechnology, University of Pavia, 27100 Pavia, Italy Edited by Catherine J. Murphy, University of Illinois at Urbana–Champaign, Urbana, IL, and approved April 11, 2019 (received for review December 13, 2018) Biological systems are subjected to continuous environmental (5–9) or intensity correlation function analysis (10). CPF analysis fluctuations, and therefore, flexibility in the structure and func- bins the photon data, obscuring fast dynamics. In contrast, inten- tion of their protein building blocks is essential for survival. sity correlation function analysis characterizes fluctuations in the Protein dynamics are often local conformational changes, which photon arrival rate, accessing dynamics down to microseconds. allows multiple dynamical processes to occur simultaneously and However, the fluorescence lifetime is a powerful indicator of rapidly in individual proteins. Experiments often average over conformation for chromoproteins and for lifetime-based FRET these dynamics and their multiplicity, preventing identification measurements, yet it is ignored in intensity-based analyses. of the molecular origin and impact on biological function. Green 2D fluorescence lifetime correlation (2D-FLC) analysis was plants survive under high light by quenching excess energy, recently introduced as a method to both resolve fast dynam- and Light-Harvesting Complex Stress Related 1 (LHCSR1) is the ics and use fluorescence lifetime information (11, 12). -
Challenges Using Linux As a Real-Time Operating System
https://ntrs.nasa.gov/search.jsp?R=20200002390 2020-05-24T04:26:54+00:00Z View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by NASA Technical Reports Server Challenges Using Linux as a Real-Time Operating System Michael M. Madden* NASA Langley Research Center, Hampton, VA, 23681 Human-in-the-loop (HITL) simulation groups at NASA and the Air Force Research Lab have been using Linux as a real-time operating system (RTOS) for over a decade. More recently, SpaceX has revealed that it is using Linux as an RTOS for its Falcon launch vehicles and Dragon capsules. As Linux makes its way from ground facilities to flight critical systems, it is necessary to recognize that the real-time capabilities in Linux are cobbled onto a kernel architecture designed for general purpose computing. The Linux kernel contain numerous design decisions that favor throughput over determinism and latency. These decisions often require workarounds in the application or customization of the kernel to restore a high probability that Linux will achieve deadlines. I. Introduction he human-in-the-loop (HITL) simulation groups at the NASA Langley Research Center and the Air Force TResearch Lab have used Linux as a real-time operating system (RTOS) for over a decade [1, 2]. More recently, SpaceX has revealed that it is using Linux as an RTOS for its Falcon launch vehicles and Dragon capsules [3]. Reference 2 examined an early version of the Linux Kernel for real-time applications and, using black box testing of jitter, found it suitable when paired with an external hardware interval timer. -
The Effect of Long Timescale Gas Dynamics on Femtosecond Filamentation
The effect of long timescale gas dynamics on femtosecond filamentation Y.-H. Cheng, J. K. Wahlstrand, N. Jhajj, and H. M. Milchberg* Institute for Research in Electronics and Applied Physics, University of Maryland, College Park, Maryland 20742, USA *[email protected] Abstract: Femtosecond laser pulses filamenting in various gases are shown to generate long- lived quasi-stationary cylindrical depressions or ‘holes’ in the gas density. For our experimental conditions, these holes range up to several hundred microns in diameter with gas density depressions up to ~20%. The holes decay by thermal diffusion on millisecond timescales. We show that high repetition rate filamentation and supercontinuum generation can be strongly affected by these holes, which should also affect all other experiments employing intense high repetition rate laser pulses interacting with gases. ©2013 Optical Society of America OCIS codes: (190.5530) Pulse propagation and temporal solitons; (350.6830) Thermal lensing; (320.6629) Supercontinuum generation; (260.5950) Self-focusing. References and Links 1. A. Couairon and A. Mysyrowicz, “Femtosecond filamentation in transparent media,” Phys. Rep. 441(2-4), 47– 189 (2007). 2. P. B. Corkum, C. Rolland, and T. Srinivasan-Rao, “Supercontinuum generation in gases,” Phys. Rev. Lett. 57(18), 2268–2271 (1986). S. A. Trushin, K. Kosma, W. Fuss, and W. E. Schmid, “Sub-10-fs supercontinuum radiation generated by filamentation of few-cycle 800 nm pulses in argon,” Opt. Lett. 32(16), 2432–2434 (2007). 3. N. Zhavoronkov, “Efficient spectral conversion and temporal compression of femtosecond pulses in SF6.,” Opt. Lett. 36(4), 529–531 (2011). 4. C. P. Hauri, R. B. -
The UNIX Time- Sharing System
1. Introduction There have been three versions of UNIX. The earliest version (circa 1969–70) ran on the Digital Equipment Cor- poration PDP-7 and -9 computers. The second version ran on the unprotected PDP-11/20 computer. This paper describes only the PDP-11/40 and /45 [l] system since it is The UNIX Time- more modern and many of the differences between it and older UNIX systems result from redesign of features found Sharing System to be deficient or lacking. Since PDP-11 UNIX became operational in February Dennis M. Ritchie and Ken Thompson 1971, about 40 installations have been put into service; they Bell Laboratories are generally smaller than the system described here. Most of them are engaged in applications such as the preparation and formatting of patent applications and other textual material, the collection and processing of trouble data from various switching machines within the Bell System, and recording and checking telephone service orders. Our own installation is used mainly for research in operating sys- tems, languages, computer networks, and other topics in computer science, and also for document preparation. UNIX is a general-purpose, multi-user, interactive Perhaps the most important achievement of UNIX is to operating system for the Digital Equipment Corpora- demonstrate that a powerful operating system for interac- tion PDP-11/40 and 11/45 computers. It offers a number tive use need not be expensive either in equipment or in of features seldom found even in larger operating sys- human effort: UNIX can run on hardware costing as little as tems, including: (1) a hierarchical file system incorpo- $40,000, and less than two man years were spent on the rating demountable volumes; (2) compatible file, device, main system software. -
TIMEDATE Time and Date Utilities
§1 TIMEDATE INTRODUCTION 1 1. Introduction. TIMEDATE Time and Date Utilities by John Walker http://www.fourmilab.ch/ This program is in the public domain. This program implements the systemtime class, which provides a variety of services for date and time quantities which use UNIX time t values as their underlying data type. One can set these values from strings, edit them to strings, convert to and from Julian dates, determine the sidereal time at Greenwich for a given moment, and compute properties of the Moon and Sun including geocentric celestial co-ordinates, distance, and phases of the Moon. A utility angle class provides facilities used by the positional astronomy services in systemtime, but may prove useful in its own right. h timedate_test.c 1 i ≡ #define REVDATE "2nd February 2002" See also section 32. 2 PROGRAM GLOBAL CONTEXT TIMEDATE §2 2. Program global context. #include "config.h" /∗ System-dependent configuration ∗/ h Preprocessor definitions i h Application include files 4 i h Class implementations 5 i 3. We export the class definitions for this package in the external file timedate.h that programs which use this library may include. h timedate.h 3 i ≡ #ifndef TIMEDATE_HEADER_DEFINES #define TIMEDATE_HEADER_DEFINES #include <stdio.h> #include <math.h> /∗ Make sure math.h is available ∗/ #include <time.h> #include <assert.h> #include <string> #include <stdexcept> using namespace std; h Class definitions 6 i #endif 4. The following include files provide access to external components of the program not defined herein. h Application include files 4 i ≡ #include "timedate.h" /∗ Class definitions for this package ∗/ This code is used in section 2.