Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: Time division multiplexing for tx vs rx  (Read 2450 times)

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Time division multiplexing for tx vs rx
« on: June 09, 2020, 10:06:25 PM »

When ADSL was originally standardised in G.992.1, why was frequency division between tx and rx chosen, not flexible time division between tx and rx ? Is the latter not how G.Fast works ?

I presume that once G.992.1 had gone that route then we were stuck with it continuing into later standards because of the demands of interoperability with older standards in a crosstalk situation on neighbouring copper lines? Not sure about how G.Fast manages to be different then, if my memory serves.
« Last Edit: June 09, 2020, 10:08:41 PM by Weaver »
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Time division multiplexing for tx vs rx
« Reply #1 on: June 09, 2020, 10:25:51 PM »

A frequency division duplex circuit operates in full duplex mode. A time division duplex circuit, with a 50:50 time split, operates in half-duplex mode.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Time division multiplexing for tx vs rx
« Reply #2 on: June 09, 2020, 10:43:43 PM »

Indeed, that was my understanding of The terms’ half duplex vs full duplex associations. I was not assuming anything about the time division split. Am I right in thinking that G.Fast is variable time division split ? (Me being too lazy to have already read the G.Fast standards doc.) A fully flexible split where, if there is nothing to transmit, then the link is turned around near-instantly, that would seem to give maximum efficiency and performance. If there’s no data to transmit in one direction then in such a hypothetical design continuous flat-out tx in the other direction should be possible at nearly 100% time usage.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Time division multiplexing for tx vs rx
« Reply #3 on: June 09, 2020, 11:00:42 PM »

I believe that the ITU-T G.Fast specification states that the time-split can be from 10:90 up to 90:10 . . . if I am remembering correctly.

I have a vague memory that BT does not use a symmetric time split but favours the DS over the US.

Perhaps ejs or j0hn (or, indeed, other members) have a better understanding of the topic?  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: Time division multiplexing for tx vs rx
« Reply #4 on: June 10, 2020, 01:28:24 AM »

Can the ratio be varied dynamically while the link is up? Or does the ratio need to be specified in some config and always kept at that (most extremely inflexible idea) but can at least be changed according to ISP, or can it be set differently each time the link comes up, or is it completely variable - alterable while the link is up at showtime?
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Time division multiplexing for tx vs rx
« Reply #5 on: June 10, 2020, 06:45:53 PM »

Again this is what I believe, from reading how BT deploy such a service, it is a predefined and invariable configuration setting. I.e. no change is possible.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: Time division multiplexing for tx vs rx
« Reply #6 on: June 10, 2020, 07:06:25 PM »

Getting back to the original question as to why FDM was chosen over TDM for ADSL, or pedantically perhaps, FDD over TDD (second ‘D’ as in ‘Duplexing’)....

...isn’t ‘reduced latency’ a good answer?

Just guessing. :)
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Time division multiplexing for tx vs rx
« Reply #7 on: June 10, 2020, 07:30:45 PM »

...isn’t ‘reduced latency’ a good answer?

Just guessing. :)

It may well have had some relevance to the duplexing method chosen, yes.

b*cat suspects that 7lm is now performing some diligent research on the topic.  ;)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: Time division multiplexing for tx vs rx
« Reply #8 on: June 10, 2020, 09:01:40 PM »

b*cat suspects that 7lm is now performing some diligent research on the topic.  ;)

You’re not wrong.   

It’s just that ‘TDM‘ in most common usage that I’ve encountered (think E1/T1) meant something different to me, hence I became curious about the question.   Once the penny dropped that time division could also be used to control duplexing, the thought occurred that it might incur a penalty in latency.   After all, if you have to wait for a period of tine until your turn to send comes around, that waiting time must surely manifest as additional latency, or so I thought?

A few minutes on Wikipedia convinced me that the idea was worth sharing.  But a few minutes on Wikipedia does not make me an expert, hence my confession that I was ‘just guessing’.  :)

And I still am.  :D
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Time division multiplexing for tx vs rx
« Reply #9 on: June 11, 2020, 01:16:22 AM »

To me, TDM is multiplexing "n" number of bi-directional circuits onto one bi-directional link, using time-slots of such a length (relationship to the frequency) so that to an observer of any one of those "n" number of circuits, it appears to be continuous. I.e. the time quanta are so small as to not be observable as discrete micro-events by a macro-object that is a human or feline being.

And TDD, to me, is the interleaving of two mono-directional data channels into on bi-directional channel between two points.

I wonder what CarlT's view of this topic might be . . .  :-\
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: Time division multiplexing for tx vs rx
« Reply #10 on: June 11, 2020, 06:59:08 AM »

Clinging to my hope that I might justify my guess...

I am reasoning that a TDM data stream in a single direction can be split into time slots that are as short as you like.  Each sequential byte on the wire might belong to a different stream of data so that when the receiver reconstructs them, the data appears to be continuous.  Each individual stream arrives a rate that is simply a fraction of the total bandwidth, without any significant added delay.

When TDM is used for duplexing, let’s call it TDD, I’d not have thought a byte by byte multiplex would work so well.   After sending a byte you’d have to wait for the propagation time until it arrived, and then wait a bit longer til the other guy’s hardware can switch his hardware from rx to tx, before another byte can be put on the wire.   For that reason, I’d have expected TDD to operate in terms of bursts of data rather than single bytes, and hence the units of time may cease to necessarily be trivial.

If TDD does operate in bursts for the reasons I speculate above, then the burst size would be a trade-off between bandwidth and latency.   No such trade off exists with FDD hence I speculate that, to achieve the same combined bandwidth, TDD will have increased latency over FDD.

Genuinely interested now.  But still guessing. :)

Edit.. changed a few TDMs/FDMs to TDD/FDD.
« Last Edit: June 11, 2020, 08:02:41 AM by sevenlayermuddle »
Logged

Alex Atkin UK

  • Addicted Kitizen
  • *****
  • Posts: 5260
    • Thinkbroadband Quality Monitors
Re: Time division multiplexing for tx vs rx
« Reply #11 on: June 11, 2020, 05:02:11 PM »

I was under the impression that the big restriction with TDM was simply CPU power required to manage those time slots.

Its become more useful as processing power per watt has gone up dramatically.
Logged
Broadband: Zen Full Fibre 900 + Three 5G Routers: pfSense (Intel N100) + Huawei CPE Pro 2 H122-373 WiFi: Zyxel NWA210AX
Switches: Netgear MS510TXUP, Netgear MS510TXPP, Netgear GS110EMX My Broadband History & Ping Monitors

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Time division multiplexing for tx vs rx
« Reply #12 on: June 11, 2020, 05:39:48 PM »

On behalf of Weaver, the topic initiator -- "Happy to read and consider all views on this topic."
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: Time division multiplexing for tx vs rx
« Reply #13 on: June 11, 2020, 11:41:51 PM »

On behalf of Weaver, the topic initiator -- "Happy to read and consider all views on this topic."

I am very deeply flattered to hear that.   So nice to be appreciated. :)
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Time division multiplexing for tx vs rx
« Reply #14 on: June 11, 2020, 11:59:03 PM »

Just a thought . . .

The two TDx entities, where x is either D or M, operate on bit-streams and not byte-streams. (That is my understanding . . . Unless I've remembered things incorrectly.)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.
Pages: [1] 2