NG7M / 2 Videos on FSK RTTY timings generated with EXTFSK/64 on new and older PC's via USB FTDI Com Ports

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

NG7M / 2 Videos on FSK RTTY timings generated with EXTFSK/64 on new and older PC's via USB FTDI Com Ports

ng7m
Hi Joe, unfortunately, you didn't watch both videos and follow the very
detailed description of the setup in the 1st bideo..  The first video is
crystal clear on a real world setup.  I'm running Win4K3Suite for CAT
control and virtual K3 feeds to 3 different com0com virtual ports for
SDR100's and I have a physical feed to my 2K-FA which shows up as a virtual
K3 etc...  All of the serial activity is on the same 8 port VSCOM USB
box... one USB connection to a 2.0 USB hub on the 8700K computer which also
has another serial usb FTDI.   I also have a full 192khz pan adapter sound
card going with Win4K3Suite pumping a UDP feed to N1MM+ to show the N1MM+
spectrum display... and MMTTY is running from N1MM+.  And a full cluster
feed going too which includes skimmer spots.  I'm not sure what real world
is based on your comments.  Plus the PC in question is recording 4K video
at 30fps and there are 2 web cams going full bore, one at 1920x1080p and
the other just under that resolution.  I had the PC loaded down more than
it ever would in a real world contest situation.

If you watch the full video you can see, even with all that heavy load,
there is no jitter as measured on the scope... unless 40 microseconds peak
to peak at 250MSa/s is meaningful jitter.  This is all show in the video.
I demonstrate it... I just to tell you about it via a post to the reflector
here.

Please, watch the full video before jumping to conclusions or make suggests
on what I should demonstrate when I have already demonstrated things you
should say I should demonstrate.

Folks got their wires crossed without watching all the content in the
videos.  Please watch all of video #1 and all of video #2 and if you
disagree, please record your own demonstration and present data and video
to show why there is still jitter under load on a multi core setup.  I
can't argue against the data and video in the demonstrations.

I made it *very clear* in the *2nd video*
<https://www.youtube.com/watch?v=L48mebqLigs> that the single core computer
didn't meet the current recommended N1MM+ hardware expectations (stated
that very clearly early on in the video).  So to be clear, the 1.1 ghz
laptop cira 2005 is not a good laptop if you going to load it up with CAT
feeds and several other devices, CAT control, multiple sound cards and
decoders, cluster feeds etc...  In fact, no one should even try to use a
single core pc at 1.1ghz to do a bunch of concurrent processing in a
"contest" like setup.  This hopefully is obvious to everyone/anyone.  Your
comments related to how bad the timings are for the second video are
relevant in that, yes... don't try to load up a system like that and run
N1MM+ and MMTTY etc... it's a bad idea! :)   So nobody should assume I was
trying to say that it was a good idea to use that setup.  Again, don't do
it.  Unless you are using something external for the timings.  TinyFSK
etc... even AFSK with timings via the sound card clock.  If you watched all
of the second video, you will also see what happens when you load the CPU
with a stress test while trying to generate FSK timings.  This is a worse
case than any contest load.  You see in the video that things pretty much
stop working as expected.

It was a WORSE CASE demonstration (nothing more) and at under low load, the
timings were NOT as bad as I expected.

The *#2 video *(*assuming everyone plows through the content*) makes that
pretty clear.  Based on rhetorical / and anecdotal comments from many
others, they would have you believe that any USB Com port generated timings
of rig based FSK are horrible and that your signals just can't be copied on
the other end of the QSO.

The* #1 first video * <https://www.youtube.com/watch?v=FN0SlOHcMQw>IMHO (
*https://www.youtube.com/watch?v=FN0SlOHcMQw*
<https://www.youtube.com/watch?v=FN0SlOHcMQw>) is more relevant to a loaded
system in the year 2018.  Please take the time to watch the first video if
you haven't already done so.  It is long... but you get a lot of detail on
how an Intel i7 8700K under high load behaves when generating USB Com Port
FSK timings.  I really hope others take the time to watch the videos before
jumping to any conclusions.  The debate in this area will never end.  That
is one thing we all can agree on.

I would be surprised if *anyone* on this list actually has an i7 8700K
setup like I demonstrate in the first video?  Anyone? Anyone?  Has anyone
ponied up for an i7 8700K running 3.2ghz DDR4 ram?  I ran the 8700K at
stock clock speeds, but usually over clock it to 5.2ghz easily across all
cores for day to day use.  It's running on a custom water loop.  I highly
doubt anyone has or will take the time in the short term to even try
recording 1 hour and 55 minutes of 4K video with two web cams running along
with multiple serial port CAT feeds going... yada, yada, yada.  We are
talking 4K 30fps video here while running N1MM+ with two spectrum displays
etc... please, see the #1 video, I detail all of this out.

In the first video above you are going to see what really is the bleeding
edge of single thread performance in a 6 core (12 logical thread Intel i7
8700K).  Believe me, what you described as a heavy load contest situation
is a stroll through the park on an i7 8700K.  It's really laughable load
for an 8700K.  And when I say laughable, I mean laughable. Please, if you
haven't done so... watch the first video. The jitter presented there under
high load while recording 4K video is in the 10s of microseconds.  Under
typical contest load the CPU in the demonstration wouldn't even break a
sweat.

If I was to pick a starting point (which is anecdotal really) for a contest
level computer, running CAT feeds and multiple serial devices and a heavy
RBN cluster feed etc... I would say that a true 4 core second or 3rd
generation Intel CPU is a good start.  However, my experience is that the
quad core AMD's do a fine job too if you don't get too crazy.

Also, has anyone actually tried to document and do any real world
measurements on SNR and FSK RTTY jitter at some repeatable level where we
have some real world numbers to back things up?  I certainly haven't.  I
would love to see some video and data.  If someone is so included, I think
you should make the measurements and present the data.  I would really love
to see it.  Take the time to setup the testing and make it repeatable and
present the data and video make your conclusions.  Then put it out for peer
review and discussion.  This is what makes this all interesting.

Again, please watch all the content in my videos, so we know we are on the
same page as to what we are talking about.  And thanks again for watching
if you have already completed reviewing all the content.

Max NG7M


--
M. George
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: NG7M / 2 Videos on FSK RTTY timings generated with EXTFSK/64 on new and older PC's via USB FTDI Com Ports

Joe Subich, W4TV-4

On 3/24/2018 8:31 PM, M. George wrote:
> Hi Joe, unfortunately, you didn't watch both videos and follow the
> very detailed description of the setup in the 1st bideo..
To the contrary, I sat through all of the redundancies of both videos.

Unfortunately, your first video is completely unrealistic as the vast
majority of amateurs uses computers significantly less powerful than
your lightly loaded (less than 40% CPU utilization by your own video)
six core, 3+ GHz CPU with the EXTFSK port on a dedicated motherboard
USB port with no loading from multiple (high priority) sound cards
(they are on a different USB Root Hub) and no contest level cluster
spots.

 From my customer support support experience, the typical amateur station
is a 2-2.4 GHz Core2Duo (two cores, 4 execution units) with 1 GB RAM and
all USB ports (typically 4) served by a single USB Root Hub.  The system
typically runs a logging program that polls one or two transceivers for
eight parameters every 50 to 100 msec along with one or two 96 or 192
KHz sample rate USB sound cards for a software panadapter (or
equivalent USB I/Q SDR receivers) and another 16 bit, 48 KHz sample
rate USB sound card for digital operation.  In addition, those systems
are connected to a DXCluster node with CW/RTTY Skimmer providing a
net spot flow of > 100 spots per minute.

I've provided jitter data as measured by microHAM in 2010 multiple times
on the RTTY list ... and that data has been verified by JA7UDE (author
of EXTFSK an ETFSK64) who also confirms the added jitter when the USB
system (single USB Root Hub) is loaded with heavy data transfer.  Oba's
results have also been reported on the RTTY list and are available on
his EXTFSK64 page.

73,

    ... Joe, W4TV


On 3/24/2018 8:31 PM, M. George wrote:

> Hi Joe, unfortunately, you didn't watch both videos and follow the very
> detailed description of the setup in the 1st bideo..  The first video is
> crystal clear on a real world setup.  I'm running Win4K3Suite for CAT
> control and virtual K3 feeds to 3 different com0com virtual ports for
> SDR100's and I have a physical feed to my 2K-FA which shows up as a virtual
> K3 etc...  All of the serial activity is on the same 8 port VSCOM USB
> box... one USB connection to a 2.0 USB hub on the 8700K computer which also
> has another serial usb FTDI.   I also have a full 192khz pan adapter sound
> card going with Win4K3Suite pumping a UDP feed to N1MM+ to show the N1MM+
> spectrum display... and MMTTY is running from N1MM+.  And a full cluster
> feed going too which includes skimmer spots.  I'm not sure what real world
> is based on your comments.  Plus the PC in question is recording 4K video
> at 30fps and there are 2 web cams going full bore, one at 1920x1080p and
> the other just under that resolution.  I had the PC loaded down more than
> it ever would in a real world contest situation.
>
> If you watch the full video you can see, even with all that heavy load,
> there is no jitter as measured on the scope... unless 40 microseconds peak
> to peak at 250MSa/s is meaningful jitter.  This is all show in the video.
> I demonstrate it... I just to tell you about it via a post to the reflector
> here.
>
> Please, watch the full video before jumping to conclusions or make suggests
> on what I should demonstrate when I have already demonstrated things you
> should say I should demonstrate.
>
> Folks got their wires crossed without watching all the content in the
> videos.  Please watch all of video #1 and all of video #2 and if you
> disagree, please record your own demonstration and present data and video
> to show why there is still jitter under load on a multi core setup.  I
> can't argue against the data and video in the demonstrations.
>
> I made it *very clear* in the *2nd video*
> <https://www.youtube.com/watch?v=L48mebqLigs> that the single core computer
> didn't meet the current recommended N1MM+ hardware expectations (stated
> that very clearly early on in the video).  So to be clear, the 1.1 ghz
> laptop cira 2005 is not a good laptop if you going to load it up with CAT
> feeds and several other devices, CAT control, multiple sound cards and
> decoders, cluster feeds etc...  In fact, no one should even try to use a
> single core pc at 1.1ghz to do a bunch of concurrent processing in a
> "contest" like setup.  This hopefully is obvious to everyone/anyone.  Your
> comments related to how bad the timings are for the second video are
> relevant in that, yes... don't try to load up a system like that and run
> N1MM+ and MMTTY etc... it's a bad idea! :)   So nobody should assume I was
> trying to say that it was a good idea to use that setup.  Again, don't do
> it.  Unless you are using something external for the timings.  TinyFSK
> etc... even AFSK with timings via the sound card clock.  If you watched all
> of the second video, you will also see what happens when you load the CPU
> with a stress test while trying to generate FSK timings.  This is a worse
> case than any contest load.  You see in the video that things pretty much
> stop working as expected.
>
> It was a WORSE CASE demonstration (nothing more) and at under low load, the
> timings were NOT as bad as I expected.
>
> The *#2 video *(*assuming everyone plows through the content*) makes that
> pretty clear.  Based on rhetorical / and anecdotal comments from many
> others, they would have you believe that any USB Com port generated timings
> of rig based FSK are horrible and that your signals just can't be copied on
> the other end of the QSO.
>
> The* #1 first video * <https://www.youtube.com/watch?v=FN0SlOHcMQw>IMHO (
> *https://www.youtube.com/watch?v=FN0SlOHcMQw*
> <https://www.youtube.com/watch?v=FN0SlOHcMQw>) is more relevant to a loaded
> system in the year 2018.  Please take the time to watch the first video if
> you haven't already done so.  It is long... but you get a lot of detail on
> how an Intel i7 8700K under high load behaves when generating USB Com Port
> FSK timings.  I really hope others take the time to watch the videos before
> jumping to any conclusions.  The debate in this area will never end.  That
> is one thing we all can agree on.
>
> I would be surprised if *anyone* on this list actually has an i7 8700K
> setup like I demonstrate in the first video?  Anyone? Anyone?  Has anyone
> ponied up for an i7 8700K running 3.2ghz DDR4 ram?  I ran the 8700K at
> stock clock speeds, but usually over clock it to 5.2ghz easily across all
> cores for day to day use.  It's running on a custom water loop.  I highly
> doubt anyone has or will take the time in the short term to even try
> recording 1 hour and 55 minutes of 4K video with two web cams running along
> with multiple serial port CAT feeds going... yada, yada, yada.  We are
> talking 4K 30fps video here while running N1MM+ with two spectrum displays
> etc... please, see the #1 video, I detail all of this out.
>
> In the first video above you are going to see what really is the bleeding
> edge of single thread performance in a 6 core (12 logical thread Intel i7
> 8700K).  Believe me, what you described as a heavy load contest situation
> is a stroll through the park on an i7 8700K.  It's really laughable load
> for an 8700K.  And when I say laughable, I mean laughable. Please, if you
> haven't done so... watch the first video. The jitter presented there under
> high load while recording 4K video is in the 10s of microseconds.  Under
> typical contest load the CPU in the demonstration wouldn't even break a
> sweat.
>
> If I was to pick a starting point (which is anecdotal really) for a contest
> level computer, running CAT feeds and multiple serial devices and a heavy
> RBN cluster feed etc... I would say that a true 4 core second or 3rd
> generation Intel CPU is a good start.  However, my experience is that the
> quad core AMD's do a fine job too if you don't get too crazy.
>
> Also, has anyone actually tried to document and do any real world
> measurements on SNR and FSK RTTY jitter at some repeatable level where we
> have some real world numbers to back things up?  I certainly haven't.  I
> would love to see some video and data.  If someone is so included, I think
> you should make the measurements and present the data.  I would really love
> to see it.  Take the time to setup the testing and make it repeatable and
> present the data and video make your conclusions.  Then put it out for peer
> review and discussion.  This is what makes this all interesting.
>
> Again, please watch all the content in my videos, so we know we are on the
> same page as to what we are talking about.  And thanks again for watching
> if you have already completed reviewing all the content.
>
> Max NG7M
>
>
______________________________________________________________
Elecraft mailing list
Home: http://mailman.qth.net/mailman/listinfo/elecraft
Help: http://mailman.qth.net/mmfaq.htm
Post: mailto:[hidden email]

This list hosted by: http://www.qsl.net
Please help support this email list: http://www.qsl.net/donate.html
Message delivered to [hidden email]