09-25-2013 10:56 AM
Hi, we have a core-edge dcx fabric (1 core dcx and 4 edge dcx) and have QOS enabled on all of our 2 port ISL trunks. We don't use QOS zones. I raised the issued based on discussions here and a site discussing the issue (Seb's IBM San Blog). Correct me if I'm wrong, but I found that using qos splits the vc's into 11 channels for data (16 vcs total) each having 2 buffer credits. For non qos isl you have 4 vcs for data (8 in total) each with 5 buffer credits each.
My reasoning was that we can disable QOS to have 20 buffer credits over the 4 vcs, or actually use QOS to separate our traffic and segregate our older 2GB hosts (acting like slow draining devices) onto the low priority QOS zones and leave medium for default traffic and possibly use high for important storage traffic or apps. In either case it would be better than having QOS enabled but not used.
We use IBM SVC, DS8000 storage and Chassis uplinks on the core switch with hosts on the edge switches. We have experienced the 2Gb hosts causing buffer credit backpressure over the ISL's on SVC which slows down the entire fabric and the 4/8Gb hosts. The best would be to refresh the 2Gb hosts but we don't have control over when they are refreshed. The plan in the future will be to isolate them to another switch.
What is the best practice recommended on QOS over the ISL if QOS zones are not used? Our IBM/Brocade reps advised us to leave QOS enabled but not to use QOS zones.
09-25-2013 12:02 PM
what i think is if you don't use qos zones, you'd better turn off qos attribute on the ports - for the reason you already explained yourself - you'll have more buffers that you can actually use.
however, this wouldn't help you with slow devices, as if they will start the back pressure, a 5 buffer queue will be filling up just a few milliseconds longer than a 2 buffer queue.
more buffers would help when your average frame size is short. you can do some simple maths to calculate average frame size, or the latest fos versions can do that for you.
bottom line: if you want to isolate your slow devices from the rest, you'd really better use qos.
if you want to have more buffer credits at the same time - this is also possible, as you can configure your isls for a longer distance than they actually are.
09-30-2013 10:46 AM
Hi, thanks for the reply. My initial recommendation was to use the QOS zones to isolate the 2Gb hosts, but Brocade and IBM didn't advise us to use QOS. When I asked why they didn't give a specific reason, just that it wasn't recommended and that they don't have any Canadian customers using QOS. They hinted that it may not behave as designed but didn't give any specific reasons. Internally there were questions has to how would we decide what went into low or high zones vs medium.
Since we use SVC and if we use QOS the backpressure may still make it back to the svc ports. I think that the ISL would be reduced as a factor of backpressure for other traffic traversing the ISL, if the older hosts went over the QOSL lanes and regular traffic over the medium priority QOS Lanes.
Do you know of any other technical reasons why QOS shouldn't be used?
09-30-2013 11:04 AM
> Do you know of any other technical reasons why QOS shouldn't be used?
no... actually, one of my customers recently started using qos for this exact purpose: to isolate critical systems from the rest of the fabric, after having a few issues with back pressure caused by slow drain devices. to be honest, i was also afraid at first =) but then we tried it and now we see that it really works!
i must note that we only have 8&16 Gb platforms here - i mean brocade switches, not the end devices...