exD konNET audio network switch

Over the years Sonore has teamed up with eXD to import interesting products for sale in the US and Canada. Today I present to you the exD konNET audio network switch. If you are interested in this item please email me at [email protected] with subject = konNET.

PRODUCT DESCRIPTION
exD konNET is a carefully designed audio network switch which dedicated to cope with the strict requirement of today’s high end audio network streaming. Unlike usual computer/IT network switches, they are only ensure proper data integrity and transmission, we pay extra attention to the finest details in improving network audio reproduction. The complete network switch is our own design from scratch and not “hot rodding” existing switch.

FEATURES
- Low Phase noise OCXO with it’s own low noise regulator ensures data and transmission stability (ppb, parts per billion stability)
- Integrated LPS (linear power supply) throughout the whole design eliminates the EMI noises from conventional SMPS (switch-mode power supply).
- Individual low-noise regulators to network chip helps improving crosstalk and other unwanted modulation among various power supply pins.
- Impedance-controlled PCB design further reduces noise and ensuring proper impedance matching.
- Modular RJ45 jack integrated with isolation magnetics shorten signal paths total length and again gives significant sonic improvement.
- Fast Ethernet (100Mbps) topology was chosen because of lower overall noise which is crucial for critical audio streaming and this speed is more than enough for the highest sample rate playback.
- Sturdy all aluminium case construction provides great vibration isolation and screening from environmental EMI/RFI.

Specification
- Ports: 5x RJ45
- Size: 210mm x 210mm x 55mm (W x D x H)
- Weight: 3kg net
- Color: Silver or Black
- Mains: 220/230V or 110/115V AC 50/60Hz (10W max)

Link to product page: https://sonore-us.myshopify.com/search?q=exd

Is there any information about the OCXO phase noise values in this switch?

With the 100 Mbps limit, it won't be able to do DSD 1024/ PCM 1.536. 

3 hours ago, Mihaylov said:

Is there any information about the OCXO phase noise values in this switch?

Hang tight…I’ll ask if they want me to share that information.

1 hour ago, bobflood said:

With the 100 Mbps limit, it won't be able to do DSD 1024/ PCM 1.536. 

Both of those (even assuming 32 bit PCM) work out to less than 100 Mb/s. 

39 minutes ago, vortecjr said:

Both of those (even assuming 32 bit PCM) work out to less than 100 Mb/s. 

It may work,but, the Ether Regen which is also 100 Mbps never worked with 1024/1.536. Besides the actual data there is the transmission overhead and the fact that it is right on the edge means that there is no surge capacity. There are a lot of threads about it from a few years ago. Not many people would ever use these rates but it is more common now than before.

DSD 1024 and PCM 1536 kHz at 24 bits are not on the edge of 100 Mbps. I’m not even certain that 1536 kHz at 32 bits is on the edge either…depends on your definition of edge. This is not an ER with its specific design so hard to compare things. The Rendu is know to work at these rates per tested from Chris C and it has a switch chip on board set to 100 Mbps. Anyway I respect eXDs decision and like the simplicity of the design. BTW It’s working great here in my system.

I am not trying to pick a fight here. I just remember well the whole controversy surrounding this issue from when the ER was released.

HQPlayer uses a 32 bit transmission container so the music data rate for 1024/1.536 is 98.3 Mbps and then there is the transmission overhead on top of that which can easily top 100 Mbps. Also, this would force a continuous feed without any surge capacity. As I said, it may work at these rates and I hope it does. Then there is the issue of does it support flow control. Jussi is like a broken record about the need for flow control at these data rates. 

I am happy that it works well for you in your system and I hope it sells well. It looks like a well built piece with a lot of care and thought put into it.

We buds and just chatting. However, your going to talk yourself out of your discussion points:) What bit rate do you thing flow control limits things to….100 Mbps. I don’t want you to assume though…If you are in a position to stream those rates then measure it and post it.

27 minutes ago, vortecjr said:

We buds and just chatting. However, your going to talk yourself out of your discussion points:) What bit rate do you thing flow control limits things to….100 Mbps. I don’t want you to assume though…If you are in a position to stream those rates then measure it and post it.

I only do DSD 256 though my UR or OR with no problems so no way to test. I was merely restating what Jussi has said on many occasions about flow control. I have switch that supports flow control so I do have it turned on. My limited understanding about flow control is that it is not data rate specific but merely attempts to prevent resends by sending packets back to the sender telling it to temporarily slow transmission.

To answer your question about flow control...I tested it with an ultraRendu hooked up to the konNET. The ultraRendu does not have an internal switch but requests flow control overt the network on boot. Everthing looks good to me as seen from the units diag page.

If your swich is managed then more likely than not you have to enable pause frames. If the switch is unmanaged then it should just work. On the Rendu you can look for the screen above to confirm things after a reboot in diag. To get to the diag page add /diag to the units IP address in your browser.   

Thanks, My two switches are managed so I do have flow control enabled on both of them. I have never had any problems at DSD 256 on either the URendu or the ORendu. On the OR, I may not be getting any flow control packets as I am still using the Gen1 OM and I don’t think it passes them. At 256 on a gig network it probably does not matter anyway. I won’t be trying to go above 256 for a long time. I am using my UltraDigital along with the UR and that is limited to 256. My Spring2 is best suited for 256 as well.

Thanks for all the advice and I wish you and Sonore continued success.

Bob

Let’s have a look…post the complete output of diag for your oR. Just add /diag to the units IP address in your browser. 

27 minutes ago, vortecjr said:

Let’s have a look…post the complete output of diag for your oR. Just 

add /diag to the units IP address in your browser. 

Big Chip

Bus 002 Device 002: ID 0424:2412 Standard Microsystems Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Disk /dev/mmcblk1: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4aa9cb1b

Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk1p1        2048    70379    68332 33.4M  e W95 FAT16 (LBA)
/dev/mmcblk1p2 *     71680   481279   409600  200M 83 Linux
/dev/mmcblk1p3      481280 31116287 30635008 14.6G 83 Linux


Disk /dev/zram0: 475.9 MiB, 499003392 bytes, 121827 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/mmcblk1p3  15056232 3915048  11113684  27% /
tmpfs             511012       0    511012   0% /sys/fs/cgroup
devtmpfs          469732       0    469732   0% /dev
tmpfs             511012       0    511012   0% /dev/shm
tmpfs             511012     432    510580   1% /run
/dev/mmcblk1p2    180560  104128     70296  60% /boot
/dev/mmcblk1p1     34015     317     33698   1% /boot/efi
tmpfs             102200       0    102200   0% /run/user/0

Kernel Interface table
eth0: flags=4163  mtu 1500
        inet 192.168.50.137  netmask 255.255.255.0  broadcast 192.168.50.255
        inet6 fe80::d263:b4ff:fe02:3564  prefixlen 64  scopeid 0x20
        inet6 2600:1700:4180:43ff:d263:b4ff:fe02:3564  prefixlen 64  scopeid 0x0
        ether d0:63:b4:02:35:64  txqueuelen 1000  (Ethernet)
        RX packets 834358254  bytes 479014433 (456.8 MiB)
        RX errors 88  dropped 7  overruns 0  frame 88
        TX packets 33263446  bytes 3652933381 (3.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 10477  bytes 1257787 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10477  bytes 1257787 (1.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

NIC statistics:
     tx_dropped: 0
     tx_packets: 64841
     tx_broadcast: 509
     tx_multicast: 11960
     tx_crc_errors: 0
     tx_undersize: 0
     tx_oversize: 0
     tx_fragment: 0
     tx_jabber: 0
     tx_collision: 0
     tx_64byte: 7704
     tx_65to127byte: 13924
     tx_128to255byte: 43045
     tx_256to511byte: 165
     tx_512to1023byte: 2
     tx_1024to2047byte: 1
     tx_GTE2048byte: 0
     tx_octets: 892537506
     IEEE_tx_drop: 0
     IEEE_tx_frame_ok: 64841
     IEEE_tx_1col: 0
     IEEE_tx_mcol: 0
     IEEE_tx_def: 0
     IEEE_tx_lcol: 0
     IEEE_tx_excol: 0
     IEEE_tx_macerr: 0
     IEEE_tx_cserr: 0
     IEEE_tx_sqe: 0
     IEEE_tx_fdxfc: 6572
     IEEE_tx_octets_ok: 892537506
     rx_packets: 9346
     rx_broadcast: 36405
     rx_multicast: 64985
     rx_crc_errors: 0
     rx_undersize: 0
     rx_oversize: 0
     rx_fragment: 0
     rx_jabber: 0
     rx_64byte: 20345
     rx_65to127byte: 19115
     rx_128to255byte: 64198
     rx_256to511byte: 44166
     rx_512to1023byte: 22836
     rx_1024to2047byte: 35294
     rx_GTE2048byte: 0
     rx_octets: 1445800870
     IEEE_rx_drop: 0
     IEEE_rx_frame_ok: 9346
     IEEE_rx_crc: 0
     IEEE_rx_align: 0
     IEEE_rx_macerr: 0
     IEEE_rx_fdxfc: 0
     IEEE_rx_octets_ok: 1445800870

Pause parameters for eth0:
Autonegotiate:	on
RX:		on
TX:		on
RX negotiated:	on
TX negotiated:	on

Pause parameters for eth1:

You have pause frame is on.

1 hour ago, vortecjr said:

You have pause frame is on.

Thanks, I saw that and was happily surprised. I thought that it wasn’t until the Gen3 OM that it worked. I never thought to check.

4 hours ago, bobflood said:

Thanks, I saw that and was happily surprised. I thought that it wasn’t until the Gen3 OM that it worked. I never thought to check.

No…pause frames is a feature of the opticalModule DX with the Broadcom IC, but it’s not related to the opticalRendu. It is related to the ultraRendu and other devices that request pause frames because they don’t directly support pause frames on board.