On 3/26/2013 2:43 AM, time-nuts-request@febo.com wrote:

Oddly enough, I had a strange way to compare two windows system today. I
had a webex meeting, and the other party opened their clock and I could
see seconds ticking away. I opened my clock, and the seconds were only
about a second apart, mostly due to latency in getting data across the
network. This isn't the first time I've done this.

This is, in reality impressive, considering the delays in moving video
data across the network. So, two windows boxes half way across the US
showed the same time to within network latency of around a second or so.
(TZ offset ignored, of course)

Keep in mind, we are after all, taking about windows. An operating
system that IS NOT real time operating system. (You think it is, try
move a continuous stream of a few 6+ MBytes/Sec data to it!)

As much as this gets to some time nuts (you know who you are! :) ), on
windows, this is good 'enuf' for me!  (Even when measuring how long it
takes to calculate PI to 80e9 places...)

Dan

On 3/26/2013 7:21 PM, Dan Kemppainen wrote:

Well, the Perseus SDR, when set to its maximum sampling rate after the DDC, sends
the I and Q continuous streams (24 bit/sample each), to the PC at a rate of 2 MHz. This
means 12 MBytes/sec via a high speed USB2 port. Using one the many available SDR
programs, those 12 MBytes/sec are received, FIR and FFT are applied, demodulation
algorithms are used, and there are no glitches in the final audio...  if even a single sample
would be lost, you would ear immediately the artifact....

Windows is not as bad as somebody would depict it... :-)

73  Alberto  I2PHD

On Tue, Mar 26, 2013 at 07:39:51PM +0100, Alberto di Bene wrote:

I have been using Windows for digital video analysis and

capture for years... often capture multiple 70-80 mb/s transport streams
by the hour from USB and PCI sources and output similar for testing.

It works.

Does take buffering and tuning in the code, and some in the

hardware.

--
Dave Emery N1PRE/AE, die@dieconsulting.com  DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in
celebration of what could have been, but wasn't and is not to be now either."

The appearent conflict here is in the definition of "real time".

For the video capture application we only need to keep up with the
average data rate and if the system stops reading data for a few tens
of milliseconds and lets it buffer in the capture hardware then it is
OK because nothing is lost.  The only criteria for success is
"nothing is lost".

The SDR application is a little more time critical because it needs to
play the proceed audio.  But again it can be buffered and we'd never
notice a 50 millisecond lag in audio and for radio  a 100 ms lag might
go unnoticed

But there is a category of what engineers ca "hard real time".  Home
computer users don't normally use their PCs for hard real time
applications.  This would be things like controlling a walking robot,
guiding an anti aircraft missile or just about any time a computer is
inside the feedback loop of a control system.  These are all
engineering and science applications that home users wouldn't see.

A "harder" real time use that people DO see in home use is music.  If
you try to do multi-track recording in a home music studio with
windows.  This can be done but people have to do thinks like (1)
remove everything non music related from the PC and disconnect it from
the network.  (2) replace the audio subsystem software with special
real-time ASIO audio drivers.  Then it can work

So ""real-time" has a wide range of meanings, video capture is about
the easiest to do and being embedded in a servo control loop the
hardest

On Tue, Mar 26, 2013 at 6:08 PM, David I. Emery die@dieconsulting.com wrote:

--

Chris Albertson
Redondo Beach, California

SDR isn't as taxing as you think. I'm running 4 of those rtlsdr type dongles on an A8-cortex. Granted under linux, but this is a single core Arm.

The "multimedia" versions of linux don't get much press these days since the kernel itself now is rather low latency. But if you google "linux musicians" or "windows musicians", there are tips for latency reduction.

One of the nicest things you can do to a computer is turn off the stupid file indexing. On windows, the program "everything" is faster than windows file search ever was, and doesn't need the index.

-----Original Message-----
From: Chris Albertson albertson.chris@gmail.com
Sender: time-nuts-bounces@febo.com
Date: Wed, 27 Mar 2013 08:38:32
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] Win XP and NIST time

The appearent conflict here is in the definition of "real time".

For the video capture application we only need to keep up with the
average data rate and if the system stops reading data for a few tens
of milliseconds and lets it buffer in the capture hardware then it is
OK because nothing is lost.  The only criteria for success is
"nothing is lost".

The SDR application is a little more time critical because it needs to
play the proceed audio.  But again it can be buffered and we'd never
notice a 50 millisecond lag in audio and for radio  a 100 ms lag might
go unnoticed

But there is a category of what engineers ca "hard real time".  Home
computer users don't normally use their PCs for hard real time
applications.  This would be things like controlling a walking robot,
guiding an anti aircraft missile or just about any time a computer is
inside the feedback loop of a control system.  These are all
engineering and science applications that home users wouldn't see.

A "harder" real time use that people DO see in home use is music.  If
you try to do multi-track recording in a home music studio with
windows.  This can be done but people have to do thinks like (1)
remove everything non music related from the PC and disconnect it from
the network.  (2) replace the audio subsystem software with special
real-time ASIO audio drivers.  Then it can work

So ""real-time" has a wide range of meanings, video capture is about
the easiest to do and being embedded in a servo control loop the
hardest

On Tue, Mar 26, 2013 at 6:08 PM, David I. Emery die@dieconsulting.com wrote:

--

Chris Albertson
Redondo Beach, California

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.