How to ignore long-running signal waits when analyzing contention using Visual Studio profiler?

Question

I tried profiling an application to see potential thread contention issues using the Visual Studio profiler, but the problem is that the profiler sees waits on signals as the worst offenders (because the consuming thread is waiting for the signal most of the time), while in reality it would be more interesting to see contention on the producing side.

E.g., I am using an asynchronous appender for log4net to reduce the impact of logging on the actual workers, and it's basically a wrapper around BlockingCollection<T>:

readonly BlockingCollection<LoggingEventContext> _queue;

protected override void Append(LoggingEvent e)
{
    // instead of appending, push to the queue
    _queue.Add(new LoggingEventContext(e, HttpContext), _loggingCancelationToken);
}

void StartForwarding()
{
    _queue = new BlockingCollection<LoggingEventContext>(BufferSize);

    _loggingCancelationTokenSource = new CancellationTokenSource();
    _loggingCancelationToken = _loggingCancelationTokenSource.Token;
    _loggingTask = new Task(SubscriberLoop, _loggingCancelationToken);
    _loggingTask.Start();
}

The long running task is where the events are forwarded to actual appenders:

void SubscriberLoop()
{
    try
    {
        // this is the blocking call which is reported as the source of contention
        foreach (var entry in _queue.GetConsumingEnumerable(_loggingCancelationToken))
        {
            HttpContext = entry.HttpContext;
            ForwardLoggingEvent(entry.LoggingEvent, ThisType);
        }
    }
    catch (OperationCanceledException ex)
    {
        ...
    }
    catch (ThreadAbortException ex)
    {
        ...
    }
}

My question is: am I doing something wrong? What is the correct way of using the profiler to identify actual hotspots?