How much bandwidth is used by a SEP Client in One day ?

Parchand,

I like the article.  However this ideal scenario would need clients connected 24 x 7.  I'm saying this because the default number of revisions in SEPM is set to 3.  That means you only have two revisions to build delta packages.  If a client is off-line for more than 24 hours (assuming SEPMS grab three updates per day) a client will be required to download the full.zip file increasing the download to over 80MB.  Here's my article on troubleshooting network bandwidth related issues with definition file updates which might come in handy for people.

https://www-secure.symantec.com/connect/articles/sepm-sep-client-bandwidth-troubleshooting

Cheers.

Jeff

Hi Prachand,

I don't get it...by my reckoning you've worked out the total number of heartbeats for 5 clients as a 5 minute heartbeat makes 12 per hour so should it not just be 12 * 24 for one client??? Also, I thought the Client uploads its logs on each heartbeat making it:
 
(2kb + 10kb) * 12 heartbeats * 24 hours * + 100kb defs (assuming 1 content update per day)

Hi Mike , The data is for one client and not 5 clients
Also the calculation also  has the logs  data added to it too.

I think instead of configure Replicatiom partners we can configure GUP.

Any suggestion?

Yes , GUP will defintly save a alot of bandwidth

So does anyone know how switching between the SEPM updates and Symantec's Live update affects bandwidth.  It used to be that connecting into Live Update would break how the xDeltas would work.  In other words, it would get the full update from Symantec (live update didn't provide the diff).  Then the next time it checked into the SEPM and got new update there, it would have to get the full update as well.  Has this changed?

It would seem that it was in Symantec's best interest to make the two models compatible (save them some bandwidth) but I can't find anything about it.

Hi Prachand,

Are you saying 10kb of logs per day or per heartbeat?

Also, this figure would obviously depend on which logs are being uploaded to the SEPM as defined in the Log Handling section of the AV policy and in the Client Log settings on the client group, could you let me know which AV events from the Log Handling tab and which logs set to upload to SEPM on the client group would be included in the 10kb logs figure?

Either way I still don't get it...maybe I'm being a bit dim but your calculation doesn't look right to me?

Please, please do correct me here if I'm wrong but using your best case scenario figures above with no IPS or policy updates:

With a heatbeat interval of 5 mins the number of heartbeats per hour = 60 mins / 5 mins = 12 heartbeats per hour

Therefore in 24 hours the number of heartbeats = 12 heartbeats per hour x 24 hours = 288 heartbeats per day

Assuming that the client uploads 10kb of logs upon each heartbeat then:

The size of the daily heartbeat package = 2kb per heartbeat + 10kb of logs per heartbeat x 288 heartbeats per day = 3456Kb per day

Add to that figure 100kb of AV defs = 3456kb daily heartbeat package + 100kb AV defs = 3556kb or 3.5 Mb per client per day

I need to get my head round this as I thought I'd worked it out right, can you clarify your calculations for me and/or correct mine please?

Thanks in advance,

Mike

INFORMATIVE

Thaks, very good infor you have given

If I am not wrong the last time when i had seen this kb the  the traffic generated for a client to and from SEPM is nearly 7 MB in One day. ((IdIf i ndsjsbfd

Has anything changed

I have sent you a PM about a query ,please respond

Prachand, hello

Could you please help with answering such question: if SEP clients are configured to download updates from "a Live Update server" will they be using delta updates, or each time full blown 140 MB update will get downloaded?

Also, if delta updates are indeed supported (which I would expect), do you happen to know how many days do LU servers keep (in other words, how many days should a client stay without updates to be forced to download full size defenitions file)?

Thanks!