VC1 & TC1

Post a reply

Confirmation code
Enter the code exactly as it appears. All letters are case insensitive.
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:
BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON
Topic review

Expand view Topic review: VC1 & TC1

Re: VC1 & TC1

Post by support » Tue Jan 16, 2018 4:32 pm


This is really interesting. Sounds like you're among the few who will actually get Virtual Channels up and running on a PC.

By all means, please report if it helped. My bet is that it won't, but I'm really interested to know if it made any difference. And I suppose there are others out there as well.

Thanks in advance,

Re: VC1 & TC1

Post by Guest » Tue Jan 16, 2018 4:16 pm

Hi Eli,

Yes, VC1 is virtual channel 1 and some specially server version supporting even 7 virtual channels.
In the TLP header of a PCIE packet there is a 3-bit-field "traffic class", so each virtual channel can be configure with a one or more classes
In this way is it possible to configure different traffic ways which are connect to different applications.

Traffic Class=0 is alway connect to VC0, this is the pcie-base configuration for each intel Ixxx-chip

Before windows is loaded, in our bootloader we see VC1 isn't enabled when the bootloader then start windows
and once runnig windows what we see is windows enabled & configure the virtual channel for the hdaudio device....

The PCH chip we use, used only this VC1 channel for audio...

But it can also be use for external pcie-devices(like I350...) which support virtual-0 & 1 channelS.
And a I350 ethernet controller and if you look on the intel website all ethernet controller specially for windows-server ... support more then one virtual channel.

But this is also true not all I7 & PCH support this VC1.. even in the same family like kabe-lake some don't other support VC1.2.3....

Any way by all this discussions and the information I find on the net, step by step I see the possibilities.

Next step try to configure in such way we could avoid the jitter on our communication port.

regards, Paul.

Re: VC1 & TC1

Post by support » Tue Jan 16, 2018 10:13 am


I don't understand. How does Windows use VC1? What does VC1 stand for? Are you sure it's Virtual Channel 1?

A rather ancient paper from Microsoft (pci-express_windows.doc, 2004) says:

Quality of Service
PCI Express defines a new feature, called virtual channels, to provide superior quality of service (QoS) compared to other I/O technologies. Virtual channels can be used to reserve bandwidth on a Link for a particular device. This reserved bandwidth provides isochronous data transfers needed to support time-sensitive applications.

Note: The PCI Express Specification defines the extended virtual channel support as an optional feature. This feature is not supported by current Windows operating systems. Because some chipsets will not support extended virtual channels while other chipsets will only implement them using non-snooped DMA, Windows Longhorn will not support this feature until better rules and guarantees are defined. Microsoft is currently working with hardware manufacturers to define these rules and guarantees.

And several Q&A's I found indicate that the situation remains the same on later Windows versions. Mind you, PCIe was introduced in Windows 7, and later Windows' kernels are pretty much the same (full driver compatibility, for example).

As I mentioned before, I don't think the problem is PCIe, but rather Windows itself. Do you have any clear indication that later Windows versions indeed supports Virtual Channels?


Re: VC1 & TC1

Post by Guest » Tue Jan 16, 2018 9:56 am


Indeed Windows use VC1 for all what's related to audio/video streaming. Just to avoid jitter in playing movies, music ....
With a pcie-tools we can see in which way windows use VC1

We develope a realtime ethernet communication driver which is involved by such movie streaming ...and which run on one core.
All other 3-cores are available for windows.

If we disable audio & video streaming all jitter is gone. Anyway I done't find no other reason which can explain this jitter.

Until know what I found on the internet, all VCx... functionality is mostly used for server applications, where they give each level that priority whats needed

regards, Paul

Re: VC1 & TC1

Post by support » Mon Jan 15, 2018 4:11 pm


That was a bit unclear, I'm afraid. PCH = Platform Controller Hub, and i210 is the Ethernet controller, but Windows using VC1? Virtual Channel 1? With what? And what data streaming? What rates?

And most important: What makes you think it's a PCIe problem? Did all the data consumers sum up to more than the PCIe bandwidth available? Otherwise, odds are you had no congestion at all. Recent systems allocate plenty of data layer credits.

A much more likely explanation for data flow issues is the operating system not keeping up with the data rate, in particular if there are poorly written drivers involved. Of the sort that tend to take mutexes, spinlocks and hold the interrupts off for too long.


Re: VC1 & TC1

Post by Guest » Mon Jan 15, 2018 3:58 pm


I use a I7 in combination with a PCH, so we connect the I210 on pcie-0 port.
But because windows use VC1 for audio, data streaming, it disturbed our communication to the I210.


Re: VC1 & TC1

Post by support » Thu Jan 11, 2018 3:47 pm

And still -- have you experienced a congestion problem with the PCIe bus? On what platform? Which bus entity is it that prevents urgent packet to flow through?

It's quite clear the virtual channels allow priority, but the question was if there is a practical scenario where this is needed and where it would actually help.


Re: VC1 & TC1

Post by Guest » Thu Jan 11, 2018 1:55 pm

Why using VC1, because it get more priority then the default VC0 interface which is located between host and pcie-bus.
Each peripheral use by default this VC0/TC0, expect far example the hdaudio,this used mostly VC1/TC1..2, when you have realtime communication then it's involve by all pcie communication to hdaudio interface.

Now I found that there are ethernet controllers who support other traffic class TC1...7, have even there own internal VC0/VC1 channels
By using such controller you can get the highest priority if you initialize the host interface/VC1 with far example TC2.
Then all pcie communication with TC = 2 passed VC1 and is not longer distrubed by the VC0 traffic.

Re: VC1 & TC1

Post by support » Thu Dec 21, 2017 1:13 pm


May I ask why you want to do this? So far, I've heard of no single practical case where applying Virtual Channels would do any good.

What's the hardware setting, expect for that not-so-impressive 1 Gbit Ethernet NIC? What is the bottleneck you're trying to resolve, and what gives you the indication that it even exists? Priority over what?


VC1 & TC1

Post by Guest » Thu Dec 21, 2017 1:04 pm


A ethernet controller Intel I210 support only VC0/TC0

I try to find a way to give this interface more priority compared with other pcie-devices in this platform who using VC0/TC0

So a idea is to place a pcie-switch between the PCIE-port of the PCH chip and the I210

Such pcie switch support VC1/TC1 <--> VC0 TC0 conversion

So when we have a i7 + pch + pcie-port <--VC1/TC1 --> pcie-switch <-- VC0/TC0--> I210

Is this a way to get more priority ? Recognize the PCH this VC1/TC1 pcie-communication ?

regards, P.