Which is pretty close to the limit for an AirFiber, based on our earlier
testing w/ small-ish packets.
Josh Reynolds :: Chief Information Officer :: SPITwSPOTS
:: Ubiquiti Certified AirMax Trainer ::
On 01/24/2014 05:12 PM, can...@believewireless.net wrote:
I just ran a test across an AirFiber link with 384 byte packets. The
interface shows it passing about 650Mbps going from an i7 x86 to a CCR
with existing Internet traffic.
On Fri, Jan 24, 2014 at 8:20 PM, Tom DeReggi
<wirelessn...@rapiddsl.net <mailto:wirelessn...@rapiddsl.net>> wrote:
Sam,
Thats quite impressive, to be able to support that many queues and
filter rules. So apparently, those key services must be multi
processor.
That is good to learn.
Eric,
Regarding single core apps. It may not matter all that much if an
app is single core, if it can use a unique core.
My concern is if key single core apps default to sharing the same
core.
Faisal,
A single 1.2G processor per port is probably fine for large
packets and Full throughput. Im concerned on whether a single 1.2G
core would be enough for full throughput with average small packet
sizes or DDOS situations. With X86 processors, in the past we've
shown it was not. But then again, the CCRs arent X86, and our past
4core X86 test machines, didnt have 36 procs to handle the load of
other processes.
Paul,
Since we are on a budget, and need something to put in place
quickly w/ SPFs, sounds like the 36core CCRs will solve our
immediate need for Core BGP Router. It clearly will do way much
better than the 1100 dual core that we temporarilly put in place,
until we had time to order in a CCR.
Whether the CCR will handle our growth plans for head end, thats
yet to be seen.
In our application we wont have nearly the number of rules per
router as Sam's example, as we do filtering and bandwidth
management at each tower, to spread out the load.
Last Question:
Long term, what Im most concerned about is how much throughput can
be passed per gig port. Meaning how close to theoretical
wirespeed. Because
when calculating a providers cost per MB, its a big difference
whether a router port can push the full GB versus say 50%.
It can double a provider's cost per MB, requiring duplicating ones
fiber infrastructure prematurely.
Has anyone tested how small the average packet size can be and
still achieve theoretical wirespeed, in a simplified configuration
over a single port?
1Gbps FDX, can 90% of that be acheived with 384k avg packet size?
Tom DeReggi
RapidDSL & Wireless, Inc
IntAirNet- Fixed Wireless Broadband
----- Original Message -----
*From:* Sam Tetherow <mailto:tethe...@shwisp.net>
*To:* WISPA General List <mailto:wireless@wispa.org>
*Sent:* Friday, January 24, 2014 5:28 PM
*Subject:* [Spam] Re: [WISPA] Mikrotik on Multi-core
Replaced an aging powerrouter 732 with a CCR-1036. Set up as a
transparent bridge for traffic shaping. Passing 478M peak with
8200 interface bridge filter rules and 8000 queue tree
entries, cpu utilization peaks at about 50 and all 36 CPUs are
in use according to /system resource cpu print
The 732 started giving us CPU limitations at about 240Mbps.
The whole thing could be reworked so we didn't have so many
filter rules or queue tree entries, but the original
installation replaced a MAC based bandwidth limiter and they
wanted to keep that setup.
Other than some lockup issues we had on ROS versions before
6.7 we have been pretty happy with the box and for under $1k
it is hard to beat.
On 01/24/2014 03:53 PM, Tom DeReggi wrote:
Hi everyone. Been awhile since Ive been here, so not sure if
this is a redundant topic or not.
Anyone got experience with Mikrotik on their newer Multi-Core
platform, using as a Core Router for interconnecting multiple
Gig backbone connections (w/ BGP, OSPF, Queues, Firewalls,
VLAN tagging)?
To be more specific.... Comparing Mikrotik's 36 core 1.2Ghz
models to say a third party Quad core 3Ghz model.
What do we need 36 cores for, when we got 11 eth ports? Are
they even used by software? Is later Mikrotik
Firmware allowing....
- multiple processors to handle a singe NIC port?
- which Mikrotik software features are able to effectively
spread accross to a unique processor or use multiple processors?
Is 1.2Ghz enough?
Do the embedded NICs in the 36core units pass full Gig
capacity? (In past, we learned depending on which NIC and
driver brand, a NIC could pass as low as only 30% of full
capacity w/ large packets, where as a later generation PCIE
w/ ATIO Intel could pass upward of 90% of full capacity w/
small packets.)
Im asking because back in the day, there were many Linux
services relating to routing that were written to be only
single processor support.
Because of this, it was important to have the highest speed
Ghz processor possible, since some critical services (the
bottleneck) would share only 1 primary processor, regardless
of how many processors were in the router.
In past experience specific to Mikrotiktik, I often ran into
issues with added features (firewall rules, Queues, etc)
drastically draining the processing power of a MT router
slowing throughput way below the theoretical published port
throughput.
For example, can Queues or Firewalls spread multiple processors?
Can these 36core units handle bandwdith management (Limiting
or Queues) for high speed subscribers, such as 100mb and 200
mbps customers?
In the GUI of v6.7, I dont see anything higher than 2mb or
10mb depending on location of parameter.
Tom DeReggi
RapidDSL & Wireless, Inc
301-515-7774 <tel:301-515-7774>
IntAirNet - Fixed Wireless Broadband
_______________________________________________
Wireless mailing list
Wireless@wispa.org <mailto:Wireless@wispa.org>
http://lists.wispa.org/mailman/listinfo/wireless
------------------------------------------------------------------------
_______________________________________________
Wireless mailing list
Wireless@wispa.org <mailto:Wireless@wispa.org>
http://lists.wispa.org/mailman/listinfo/wireless
_______________________________________________
Wireless mailing list
Wireless@wispa.org <mailto:Wireless@wispa.org>
http://lists.wispa.org/mailman/listinfo/wireless
_______________________________________________
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
_______________________________________________
Wireless mailing list
Wireless@wispa.org
http://lists.wispa.org/mailman/listinfo/wireless
